<lekernel__>
looks much better than what networkx/matplotlib gives
* Fallenou
coughs
<Fallenou>
M$ Word 2010
<Fallenou>
sorry
<Fallenou>
with hand placed arrows and squares
<mwalle>
lekernel__: never used shiny ms products? :)
<lekernel__>
the most recent windows I have used is XP
<mwalle>
lekernel__: btw the lm32_cpu can store the register in blockram which uses a clock shifted by 180deg. that way you can save some registers
<mwalle>
do you think that is also possible on spartan-6?
<lekernel__>
the register file?
<mwalle>
yeah
<lekernel__>
isn't it already in block ram?
<lekernel__>
if you disable the reset
<lekernel__>
and this doesn't need a shifted clock
<mwalle>
there are two options, CFG_EBR_POSEDGE_REGISTER_FILE and CFG_EBR_NEGEDGE_REGISTER_FILE
<mwalle>
we use the first atm
<mwalle>
the first need some additional buffers
<lekernel__>
what buffers?
<lekernel__>
let me check the source ...
<mwalle>
buffers in terms of data buffers, some registers to store intermediate data
<lekernel__>
you mean it adds a pipeline stage?
<mwalle>
no
<mwalle>
it seems to stall the cpu if there is a read and write at the same time
<lekernel__>
ah, I think I understand
<lekernel__>
since it's a dual port RAM, there is a conflict if you read two operands and write one?
<lekernel__>
(you'd rather need 3 ports)
<mwalle>
they use two rams for the 3 ports
<lekernel__>
yeah, right :) otherwise performance would suck
<mwalle>
and writes go to both
<mwalle>
"One limitation of the on-chip block RAMs is that one cannot perform a read and write to same location in a cycle (if this is done, then the data read out is indeterminate)"
<lekernel__>
I'm not sure xilinx has this limitation... in either case, how does clocking the RAM with the opposite clock edge resolves the problem?
<mwalle>
ah,
<lekernel__>
you do writes with one edge and reads with the other?
<mwalle>
write clock is clk_n
<mwalle>
err
<mwalle>
read clock is clk_n and write clock is clk
<mwalle>
actuall the define has a bad name..
<lekernel__>
I would guess either the xilinx silicon doesn't have this limitation, or Xst inserts appropriate conflict detection logic automatically (in which case the corresponding code in lm32_cpu.v serves the only purpose of increasing SLOC)
<lekernel__>
and I think this is the right thing to do btw
<mwalle>
"this" ?
<lekernel__>
not having the limitation in silicon, or letting the synthesizer take care of it to match the behavioral code
<mwalle>
ah :)
<mwalle>
well they used the ram slice directly.. so.. ;)
<lekernel__>
that's also not a good thing to do :)
<lekernel__>
and this negative clock is very much a hack... should be removed completely imo
<lekernel__>
I think the overhead of the conflict detection logic is too small to justify it
<lekernel__>
also, block RAMs sometimes have large setup or clock-to-output times... need to be careful when messing with clocks, otherwise you can end up with a slow design
<lekernel__>
for example, clocking reads on the negative edge to do asynchronous reads (which aren't supported by silicon) is a sure way to have lousy performance
<mwalle>
lekernel__: according to ug383 there are two clock inputs