<div>Yes, I've tried compiling the project and saw that warning, that sys_eim_rd is not used.</div><div>š</div><div>Paul, in my baseline project I've included a testbench (tb_demo_adder.v) that simulates complete demo adder core operation. It writes X and Y operands, modifies control register to trigger addition, then polls status register and reads Z=X+Y register from the adder core. This testbench has two tasks, namely eim_write and eim_read, that simulate write and read transactions from the CPU. You can modify the original testbench to debug operation of your cores, if you need.</div><div>š</div><div>Please have a look at the attached pictures: sys_eim_addr, sys_eim_wr, sys_eim_rd and sys_eim_dout are asserted simultaneously (sys_eim_dout is only assigned during write transactions). Flags become active for one cycle, so our cores should handle transactions as soon one of the flags is set. During read transaction arbiter internally delays read flag (sys_req_dly signal in the waveforms) for one additional cycle to allow user logic to place read value into eim_data_in register. This value is then latched and sent to the CPU. If our cores have registered outputs, then core multiplexor should be non-pipelined to match latency expected by EIM arbiter. If pipelined multiplexor is needed, then one more bit should be added to sys_req_dly to increase arbiter latency by one cycle. Pipelined multiplexor consumes more slices, but makes meeting internal timing constraints easier. I'll take a closer look at this issue tomorrow. I should be not very difficult to fix it.</div><div>š</div><div>05.02.2015, 23:42, "Paul Selkirk" <paul@psgd.org>:</div><blockquote type="cite"><p>I just pushed branch coretest_hashes, which, as you might assume,<br />contains all the SHA hash cores. It works. Many thanks to Pavel and<br />Joachim for getting us to this point.<br /><br />The one strange thing I found (which you can see in core_selector.v) is<br />that I wasn't able to use (sys_eim_wr|sys_eim_rd) for cs, but had to<br />rely solely on sys_eim_addr. I noticed that Joachim basically did the<br />same thing in his earlier version. I haven't looked to see if the timing<br />is different for the rd/wr controls vs the address. Maybe Pavel can shed<br />some light on this?<br /><br />ššššššššššššššššššššššššššššššššpaul<br /><br />PS. Time to blag... (Then time to gather lots of random numbers, write a<br />cryptlib HAL, etc.)<br /><br />On 02/04/2015 06:13 PM, Paul Selkirk wrote:</p><blockquote>šUm, might want to clean it up just a touch, like to the point where<br />šit'll do all the hashes. As Joachim said, the current code only does<br />šSHA-256, and is a bit of a dog's breakfast.<br /><br />šššššššššššššššššššššššššššššššššpaul<br /><br />šOn 02/04/2015 05:02 PM, Leif Johansson wrote:<br /><blockquote>šthis may be the time to start that blog...</blockquote>š_______________________________________________<br />šTech mailing list<br />š<a href="mailto:Tech@cryptech.is">Tech@cryptech.is</a><br />š<a href="https://lists.cryptech.is/listinfo/tech">https://lists.cryptech.is/listinfo/tech</a></blockquote><p>_______________________________________________<br />Tech mailing list<br /><a href="mailto:Tech@cryptech.is">Tech@cryptech.is</a><br /><a href="https://lists.cryptech.is/listinfo/tech">https://lists.cryptech.is/listinfo/tech</a></p></blockquote><div>š</div><div>š</div><div>-- <br />σ ΥΧΑΦΕΞΙΕΝ, ϋΑΤΟΧ πΑΧΕΜ.</div><div>š</div>