Re: gEDA-user: bidirectional delay in verilog?

[carzrgr8@xxxxxxxxxxxxx]

Ok.  I peeked at your verilog code, not too closely, just a little so I may make a mistake.  
There are 2 IO ports, RamData and mcuData both defined as inout so you can tristate 
there outputs to world.  Looks like you are connecting ramData to mcuData by latching 
one side, then driving out to the other and vise-versa.

XST is going to put those tristate drivers in the IOB's.  The registers may or may not be 
put into the IOB but I guess probably not.  You can get the prop delays from the place 
and route results.  Use that value in your statements to add the output (IOB) delay to your 
code.  The synthesizer doesn't care, it'll ignore it.  So maybe something like this:

parameter IOB_DELAY = 10;
assign mcu_data = #IOB_DELAY my_mcu_data;
assign ram_data = #IOB_DELAY my_ram_data;

Just remember to setup the correct delay steps at the beginning of your code:
`timescale 1ns/1ps   

which is 1ns step size, with 1ps resolution on the simulator.

Modeling your code functionally, with just this simple change will get you the delay for the 
IOB.  You'll have to check for timing violations manually though.

you could modify the delay time period to include the flight time:
parameter IOB_DELAY = 10;
parameter FLIGHT_TIME = 3;
parameter OUTPUT_DELAY = IOB_DELAY + FLIGHT_TIME:
assign mcu_data = #OUTPUT_DELAY my_mcu_data;
assign ram_data = #DELAY_DELAY my_ram_data;

Something like that.  You have the micron verilog code which you could modify to 
include the flight times too.  If it's too difficult to weed through their code, modify your 
code on the input side to include the flight time too:

else if (~mcu_nwr) begin
	   my_ram_data = #FLIGHT_TIME mcu_data;


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user