Skip to content

V
VME64x core
Commit 131c5766 authored by Tristan Gingold's avatar Tristan Gingold
Browse files
Options

Update review document after 2017-11-13 review.

parent 34239178
Show whitespace changes
Inline Side-by-side
Showing with 109 additions and 54 deletions
doc/review-2017-11-13/GD-vme64x-core-review.txt
View file @ 131c5766
- top VME64x core entity is called "VME64xCore_Top" while - top VME64x core entity is called "VME64xCore_Top" while
svec/hdl/top/vmecore_test/ instantiates vme64xcore_top. Make it the same (all svec/hdl/top/vmecore_test/ instantiates vme64xcore_top. Make it the same (all
lower-case?) for easier grepping. lower-case?) for easier grepping.
OK.
- check comments in all the files, some of them are not complete or out of date - check comments in all the files, some of them are not complete or out of date
OK.
- shall we have some reference design in the VME64x core repo? With necessary - shall we have some reference design in the VME64x core repo? With necessary
constraints for the clock and putting registers in IOBs (like vme_irq_n_o in constraints for the clock and putting registers in IOBs (like vme_irq_n_o in
svec vmecore_test) svec vmecore_test)
Points to the svec repo.
- vme64x_pack.vhd -> we usually call these things *_pkg.vhd - vme64x_pack.vhd -> we usually call these things *_pkg.vhd
OK
- from files headers remove _last changes_ and _TODO_ sections, anyway, they are - from files headers remove _last changes_ and _TODO_ sections, anyway, they are
empty. empty.
OK.
- i'd prefer to have signals without "s_" prefix, but this is part of a larger - i'd prefer to have signals without "s_" prefix, but this is part of a larger
coding style discussion. coding style discussion.
In this design most of the signals are with "s_" prefix, but some are also In this design most of the signals are with "s_" prefix, but some are also
without (e.g. in VME_IRQ_Controller.vhd) without (e.g. in VME_IRQ_Controller.vhd)
'Detail'.
- how about using t_vme64x_in and t_vme64x_out types inside the design to make - how about using t_vme64x_in and t_vme64x_out types inside the design to make
the core more compact and having only an std_logic wrapper for simulations? the core more compact and having only an std_logic wrapper for simulations?
Good convention to be adopted.
- vme64x_pack.vhd and xvme64x_core_pkg.vhd should be merged into one package - vme64x_pack.vhd and xvme64x_core_pkg.vhd should be merged into one package
OK.
------------------------ ------------------------
-- vme64x_pack.vhd -- -- vme64x_pack.vhd --
...@@ -23,29 +31,39 @@ ...@@ -23,29 +31,39 @@
rename c_CLOCK_PERIOD to something like c_default_CLK_PERIOD rename c_CLOCK_PERIOD to something like c_default_CLK_PERIOD
because as far as I've seen in the code, that's what it is, a default clk because as far as I've seen in the code, that's what it is, a default clk
period value assigned to g_CLOCK_PERIOD if user does not overwrite it. period value assigned to g_CLOCK_PERIOD if user does not overwrite it.
Default to be removed.
- line 55: - line 55:
c_ADEM_M is a type not a constant, rename it to t_ADEM_M c_ADEM_M is a type not a constant, rename it to t_ADEM_M
Add a comment.
- cleanup, remove types that are not used e.g. c_ADER_C_XAM or c_ADER_C_AM - cleanup, remove types that are not used e.g. c_ADER_C_XAM or c_ADER_C_AM
Add a comment as unused.
------------------------ ------------------------
-- VME64xCore_Top.vhd -- -- VME64xCore_Top.vhd --
------------------------ ------------------------
- if g_WB_DATA_WIDTH must be 32-bit, then don't make it a generic, just use - if g_WB_DATA_WIDTH must be 32-bit, then don't make it a generic, just use
everywhere c_DATA_WIDTH declared in the package everywhere c_DATA_WIDTH declared in the package
OK: to be removed.
- the same for g_WB_ADDR_WIDTH (see also comment for VME_bus.vhd) - the same for g_WB_ADDR_WIDTH (see also comment for VME_bus.vhd)
OK: to be removed.
- prefix Wishbone ports with "wb_" - prefix Wishbone ports with "wb_"
OK.
- if you make VME_bus.vhd with reset active low, then you don't need s_reset - if you make VME_bus.vhd with reset active low, then you don't need s_reset
signal anymore (see also comment in VME_bus.vhd). signal anymore (see also comment in VME_bus.vhd).
OK.
------------------------ ------------------------
-- VME_bus.vhd -- -- VME_bus.vhd --
------------------------ ------------------------
- prefix Wishbone ports with "wb_" - prefix Wishbone ports with "wb_"
OK.
- either fix adr_o handling or remove g_WB_ADDR_WIDTH because setting anything - either fix adr_o handling or remove g_WB_ADDR_WIDTH because setting anything
else than 32-bit to g_WB_ADDR_WIDTH will result in synthesis/simulation error else than 32-bit to g_WB_ADDR_WIDTH will result in synthesis/simulation error
OK.
- why reset is active high (rst_i) and not active low like in all other modules? - why reset is active high (rst_i) and not active low like in all other modules?
OK.
- constant num_latchDS misses "c_" prefix - constant num_latchDS misses "c_" prefix
OK.
- line 431: 3 nested if-s. How about simplifying to: - line 431: 3 nested if-s. How about simplifying to:
if decode_done_i = '1' and decode_sel_i = '1' and module_enable_i = '1'then if decode_done_i = '1' and decode_sel_i = '1' and module_enable_i = '1'then
(...) (...)
...@@ -54,11 +72,13 @@ ...@@ -54,11 +72,13 @@
else else
s_mainFSMstate <= DECODE_ACCESS; s_mainFSMstate <= DECODE_ACCESS;
end if; end if;
'As you like'.
- line 461: - line 461:
should you check if s_DS_latch_count >0 before decrementing it by 1? should you check if s_DS_latch_count >0 before decrementing it by 1?
if for whatever reason you stay longer in DECODE_ACCESS waiting for if for whatever reason you stay longer in DECODE_ACCESS waiting for
decode_done_i='1' you might end up going to WAIT_FOR_DS when your counter is decode_done_i='1' you might end up going to WAIT_FOR_DS when your counter is
already 0, then after your decrement your counter rolls over already 0, then after your decrement your counter rolls over
OK.
-------------------------- --------------------------
-- VME_CR_CSR_Space.vhd -- -- VME_CR_CSR_Space.vhd --
...@@ -66,6 +86,7 @@ ...@@ -66,6 +86,7 @@
- line 323: - line 323:
can use xor_reduce(vme_ga_i) from std_logic_misc instead of manually xoring can use xor_reduce(vme_ga_i) from std_logic_misc instead of manually xoring
all the bits all the bits
No, because std_logic_misc is not standard.
-------------------------- --------------------------
-- VME_Funct_Match.vhd -- -- VME_Funct_Match.vhd --
...@@ -75,21 +96,26 @@ ...@@ -75,21 +96,26 @@
Instead of clearing the registers at every risinge_edge, and having null in Instead of clearing the registers at every risinge_edge, and having null in
rst_n_i='0', please clear the registers when rst_n_i ='0' and add another rst_n_i='0', please clear the registers when rst_n_i ='0' and add another
"else" if you want to clear them every time decode_start_i='0'. "else" if you want to clear them every time decode_start_i='0'.
OK.
- line 133: - line 133:
What's this construction??: What's this construction??:
mask(c_ADEM_M) := g_ADEM(s_function_sel)(c_ADEM_M); mask(c_ADEM_M) := g_ADEM(s_function_sel)(c_ADEM_M);
where c_ADEM_M is a subtype is integer range 31 downto 8; where c_ADEM_M is a subtype is integer range 31 downto 8;
Covered.
---------------------------- ----------------------------
-- VME_IRQ_Controller.vhd -- -- VME_IRQ_Controller.vhd --
---------------------------- ----------------------------
- reset_n_i, we always name it rst_n_i - reset_n_i, we always name it rst_n_i
OK.
- line 170: - line 170:
very very tiny thing, retry_count can be cleared always when we're in very very tiny thing, retry_count can be cleared always when we're in
WAIT_IRQ (not only inside the _if_). This simplifies an already simple fsm. WAIT_IRQ (not only inside the _if_). This simplifies an already simple fsm.
'Tiny'.
---------------------------- ----------------------------
-- simulation -- -- simulation --
---------------------------- ----------------------------
- general-cores submodule in wrong location. Move it from hdl/sim to - general-cores submodule in wrong location. Move it from hdl/sim to
ip_cores/general-cores like we have for all the other repos. ip_cores/general-cores like we have for all the other repos.
Cf Maciej.
doc/review-2017-11-13/ML-vme64x-review.txt
View file @ 131c5766
...@@ -24,14 +24,19 @@ about simulatin will come first): ...@@ -24,14 +24,19 @@ about simulatin will come first):
how to make the simulation. Moreover, the existing README in the main how to make the simulation. Moreover, the existing README in the main
folder is out-of-date. folder is out-of-date.
I see several improvements that are spread among several points below. I see several improvements that are spread among several points below.
OK: let's follow this convention.
0.2. I would recommend to follow our folder convention (which used to be on 0.2. I would recommend to follow our folder convention (which used to be on
ohwr.org and which is now gone, probably due to migration, so I copy+paste ohwr.org and which is now gone, probably due to migration, so I copy+paste
it at the end of this file). Using this convention would require the it at the end of this file). Using this convention would require the
following changes: following changes:
a) change /documents to /docs a) change /documents to /doc
Done.
b) change hdl/sim to hdl/testbench b) change hdl/sim to hdl/testbench
c) possibly movig hdl/sim/vme64x_bfm to hdl/sim/vme64x_bfm if this is a OK.
c) keep vme64x_bfm in hdl/sim/vme64x_bfm if this is a
model of the vme64x (I do not know because it is undocumented) model of the vme64x (I do not know because it is undocumented)
OK.
0.3. the arrangement of simple_tb is confusing: first I thought that the folder 0.3. the arrangement of simple_tb is confusing: first I thought that the folder
"modelsim" contains some modelsim-specific stuff. Again, how should I know "modelsim" contains some modelsim-specific stuff. Again, how should I know
if there is no description/documentation/README. I'd recommend to do one if there is no description/documentation/README. I'd recommend to do one
...@@ -39,7 +44,9 @@ about simulatin will come first): ...@@ -39,7 +44,9 @@ about simulatin will come first):
a) move content from hdl/sim/simple_tb/modelsim/ to hdl/sim/simple_tb a) move content from hdl/sim/simple_tb/modelsim/ to hdl/sim/simple_tb
(preferred if there are no plans to add simulation for other tools) (preferred if there are no plans to add simulation for other tools)
b) add README explaining this structure b) add README explaining this structure
Add a README.
0.4. hdl/sim/simple_tb/modelsim/run_all.sh is not working [committed fix] 0.4. hdl/sim/simple_tb/modelsim/run_all.sh is not working [committed fix]
OK.
0.5. It would be extremely useful to have some waveforms when running simulation. 0.5. It would be extremely useful to have some waveforms when running simulation.
I recommend doing one of the following: I recommend doing one of the following:
a) modify run_all.sh to show the run simulations in waveform a) modify run_all.sh to show the run simulations in waveform
...@@ -48,6 +55,7 @@ about simulatin will come first): ...@@ -48,6 +55,7 @@ about simulatin will come first):
signals. Ideally, the documentation provided to the user would match the signals. Ideally, the documentation provided to the user would match the
waveform so that when a developer runs the simulation, he can easily map waveform so that when a developer runs the simulation, he can easily map
the output to the documentation. the output to the documentation.
OK with b).
0.6. Add general-cores as submodule in /hdl/ip_cores [committed] 0.6. Add general-cores as submodule in /hdl/ip_cores [committed]
even if vme64x is never used standalone and general-cores are used in this even if vme64x is never used standalone and general-cores are used in this
project only when running simulation, I would still include it as submodule project only when running simulation, I would still include it as submodule
...@@ -56,15 +64,20 @@ about simulatin will come first): ...@@ -56,15 +64,20 @@ about simulatin will come first):
know which ip_cores and which version he/she needs know which ip_cores and which version he/she needs
b) to make the simulation easier to to run b) to make the simulation easier to to run
c) it seems to be a general policy c) it seems to be a general policy
OK.
0.7. README in the main directory is completely out of date ! 0.7. README in the main directory is completely out of date !
OK.
0.8. /documention folder: 0.8. /documention folder:
- the notes from the 2012 review should stay, - the notes from the 2012 review should stay,
Still in the repo.
- a new folder for the current review should be added. - a new folder for the current review should be added.
Done.
- I would guess that some of the removed documents will be replaced with - I would guess that some of the removed documents will be replaced with
updated versions. If this is not the case, it seems to me that the updated versions. If this is not the case, it seems to me that the
currently provided documentation (the one reminding in the folder) is currently provided documentation (the one reminding in the folder) is
NOT sufficient. At least, the vme64x_user_manual should be revived. NOT sufficient. At least, the vme64x_user_manual should be revived.
Moreover, the documentation in the project files seems to be out-of-date. Moreover, the documentation in the project files seems to be out-of-date.
OK.
0.9. consider refactoring as follows: 0.9. consider refactoring as follows:
(see https://www.ohwr.org/attachments/554/VHDLcoding.pdf) (see https://www.ohwr.org/attachments/554/VHDLcoding.pdf)
- the convention of prefix s_ for signals is generally avoided, remove s_ - the convention of prefix s_ for signals is generally avoided, remove s_
......
doc/review-2017-11-13/dlamprid-vme64x_review.org
View file @ 131c5766
* General notes * General notes
- pull dlamprid-vme64x_review for both the core and the SVEC demo (vmecore_test) - pull dlamprid-vme64x_review for both the core and the SVEC demo (vmecore_test)
+ adjust/merge as you see fit + adjust/merge as you see fit
Done
- [Update]/[Delete] top-level README.txt? - [Update]/[Delete] top-level README.txt?
Done
- [Update] HDL headers - [Update] HDL headers
OK.
- [Update]/[Delete]/[Move to user manual] header comments with technical explanations? - [Update]/[Delete]/[Move to user manual] header comments with technical explanations?
OK.
- Good opportunity to rename files, entities and instances. eg: - Good opportunity to rename files, entities and instances. eg:
+ pack or pkg? + pack or pkg?
_pkg (same name as the design unit name).
+ capital or small case file names? + capital or small case file names?
The same case, lower case.
+ ... + ...
- does not strictly follow proposed folder structure - does not strictly follow proposed folder structure
See Maciej comment
* VME64x core * VME64x core
- get rid of SVEC_ID, CERN_ID etc from package and default generic values - get rid of SVEC_ID, CERN_ID etc from package and default generic values
OK for default generic
- what happens if the c_CLOCK_PERIOD is wrong? maybe it's better to get rid of it, set g_CLOCK_PERIOD by default to zero and assert that it is set to something else by user - what happens if the c_CLOCK_PERIOD is wrong? maybe it's better to get rid of it, set g_CLOCK_PERIOD by default to zero and assert that it is set to something else by user
OK.
- shal we name/label all processes? - shal we name/label all processes?
NO, but...
** VME64xCore_top.vhd ** VME64xCore_top.vhd
- Add generic/constant for number of supported functions and use it to limit size of ader/adem - Add generic/constant for number of supported functions and use it to limit size of ader/adem
arrays etc, in order to reduce number of warnings in ISE (from ~450 to ~50) arrays etc, in order to reduce number of warnings in ISE (from ~450 to ~50)
Ok.
- gc_sync_register: does it even make sense? Slide #95 of NASA radiation tolerant design presentation: - gc_sync_register: does it even make sense? Slide #95 of NASA radiation tolerant design presentation:
https://indico.cern.ch/event/663761/contributions/2710422/attachments/1537821/2410163/Berg_SynchronousDesign_2017.pdf https://indico.cern.ch/event/663761/contributions/2710422/attachments/1537821/2410163/Berg_SynchronousDesign_2017.pdf
No problem, discussion about width postponed.
*** VME_CR_CSR_Space.vhd *** VME_CR_CSR_Space.vhd
- delete unused port vme_sysfail_ena_o? - delete unused port vme_sysfail_ena_o?
OK.
* Simulation * Simulation
- how am I supposed to run it? A README would help - how am I supposed to run it? A README would help
- why open the GUI at the end of make? - why open the GUI at the end of make?
OK.
- why keep around VME BFM if you are not using it? Why the SVEC-specific file in the VME BFM? - why keep around VME BFM if you are not using it? Why the SVEC-specific file in the VME BFM?
Removed. To be restored.
- why not (also) GHDL if Modelsim is not necessary? - why not (also) GHDL if Modelsim is not necessary?
Shouldn't be hard, excercise let to the reader.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment