Commit 131c5766 authored by Tristan Gingold's avatar Tristan Gingold

Update review document after 2017-11-13 review.

parent 34239178
- top VME64x core entity is called "VME64xCore_Top" while
svec/hdl/top/vmecore_test/ instantiates vme64xcore_top. Make it the same (all
lower-case?) for easier grepping.
OK.
- 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
constraints for the clock and putting registers in IOBs (like vme_irq_n_o in
svec vmecore_test)
Points to the svec repo.
- vme64x_pack.vhd -> we usually call these things *_pkg.vhd
OK
- from files headers remove _last changes_ and _TODO_ sections, anyway, they are
empty.
OK.
- i'd prefer to have signals without "s_" prefix, but this is part of a larger
coding style discussion.
In this design most of the signals are with "s_" prefix, but some are also
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
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
OK.
------------------------
-- vme64x_pack.vhd --
......@@ -23,29 +31,39 @@
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
period value assigned to g_CLOCK_PERIOD if user does not overwrite it.
Default to be removed.
- line 55:
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
Add a comment as unused.
------------------------
-- VME64xCore_Top.vhd --
------------------------
- 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
OK: to be removed.
- the same for g_WB_ADDR_WIDTH (see also comment for VME_bus.vhd)
OK: to be removed.
- prefix Wishbone ports with "wb_"
OK.
- 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).
OK.
------------------------
-- VME_bus.vhd --
------------------------
- prefix Wishbone ports with "wb_"
OK.
- 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
OK.
- why reset is active high (rst_i) and not active low like in all other modules?
OK.
- constant num_latchDS misses "c_" prefix
OK.
- 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
(...)
......@@ -54,11 +72,13 @@
else
s_mainFSMstate <= DECODE_ACCESS;
end if;
'As you like'.
- line 461:
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
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
OK.
--------------------------
-- VME_CR_CSR_Space.vhd --
......@@ -66,6 +86,7 @@
- line 323:
can use xor_reduce(vme_ga_i) from std_logic_misc instead of manually xoring
all the bits
No, because std_logic_misc is not standard.
--------------------------
-- VME_Funct_Match.vhd --
......@@ -75,21 +96,26 @@
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
"else" if you want to clear them every time decode_start_i='0'.
OK.
- line 133:
What's this construction??:
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;
Covered.
----------------------------
-- VME_IRQ_Controller.vhd --
----------------------------
- reset_n_i, we always name it rst_n_i
OK.
- line 170:
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.
'Tiny'.
----------------------------
-- simulation --
----------------------------
- general-cores submodule in wrong location. Move it from hdl/sim to
ip_cores/general-cores like we have for all the other repos.
Cf Maciej.
......@@ -24,14 +24,19 @@ about simulatin will come first):
how to make the simulation. Moreover, the existing README in the main
folder is out-of-date.
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
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
following changes:
a) change /documents to /docs
a) change /documents to /doc
Done.
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)
OK.
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
if there is no description/documentation/README. I'd recommend to do one
......@@ -39,7 +44,9 @@ about simulatin will come first):
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)
b) add README explaining this structure
Add a README.
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.
I recommend doing one of the following:
a) modify run_all.sh to show the run simulations in waveform
......@@ -48,6 +55,7 @@ about simulatin will come first):
signals. Ideally, the documentation provided to the user would match the
waveform so that when a developer runs the simulation, he can easily map
the output to the documentation.
OK with b).
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
project only when running simulation, I would still include it as submodule
......@@ -56,15 +64,20 @@ about simulatin will come first):
know which ip_cores and which version he/she needs
b) to make the simulation easier to to run
c) it seems to be a general policy
OK.
0.7. README in the main directory is completely out of date !
OK.
0.8. /documention folder:
- the notes from the 2012 review should stay,
Still in the repo.
- a new folder for the current review should be added.
Done.
- 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
currently provided documentation (the one reminding in the folder) is
NOT sufficient. At least, the vme64x_user_manual should be revived.
Moreover, the documentation in the project files seems to be out-of-date.
OK.
0.9. consider refactoring as follows:
(see https://www.ohwr.org/attachments/554/VHDLcoding.pdf)
- the convention of prefix s_ for signals is generally avoided, remove s_
......
* General notes
- pull dlamprid-vme64x_review for both the core and the SVEC demo (vmecore_test)
+ adjust/merge as you see fit
Done
- [Update]/[Delete] top-level README.txt?
Done
- [Update] HDL headers
OK.
- [Update]/[Delete]/[Move to user manual] header comments with technical explanations?
OK.
- Good opportunity to rename files, entities and instances. eg:
+ pack or pkg?
_pkg (same name as the design unit name).
+ capital or small case file names?
The same case, lower case.
+ ...
- does not strictly follow proposed folder structure
See Maciej comment
* VME64x core
- 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
OK.
- shal we name/label all processes?
NO, but...
** VME64xCore_top.vhd
- 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)
Ok.
- 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
No problem, discussion about width postponed.
*** VME_CR_CSR_Space.vhd
- delete unused port vme_sysfail_ena_o?
OK.
* Simulation
- how am I supposed to run it? A README would help
- 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?
Removed. To be restored.
- 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