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,18 +72,21 @@
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 --
--------------------------
- 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);
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.
This diff is collapsed.
* 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