Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On 2/15/2013 12:59 PM, RCIngham wrote: > Does anyone know why ModelSim version numbers skipped from 6.6 to 10, > missing out 7, 8,and 9? > > Thanks in anticipation. It might have something to do with the rumor that Microsoft has patented the numbers 7, 8 and 9. They would have patented 1 through 6 but Apple beat them to it. Hmmm... I wonder if anyone has patented 11 yet... better yet, just patent all the real numbers in one swell foop! But please exclude the transcendentals, there's no justification for patenting pi. :( -- RickArticle: 154926
> I am especially interrested in ddr ram / (arm) ahb-lite wrapping : > mig/mpmc xilinx tools dont have wizard for that bus, it shoud be doable, but tricky... is there something freely available ?? Take a look at grlib from Gaisler Research. regards BartArticle: 154927
Martin Thompson wrote:
> Heinz-Jürgen Oertel <hj.oertel@t-online.de> writes:
>
>> Hello,
>> might not be a real FPGA question,
>> but I hope that some of you doing not only the hardware part
>> but also working with the Xilinx SDK.
>> I try to use the CAN controller on e ZedBoard under Linux.
>> I *think* that I have done the CAN_L and CAN_H routing correct
>> to the FMC connector. Now I read and write to the CAN controller
>> registers. It seems to be correct, if I look what I'm reading back.
>> BUT, nothing happens at the CAN lines at the FMC connector.
>> What am I missing?
>> Do I need special clock settings in some other register, not CAN.
>> Or What else has to be programmed in order to get the CAN working?
>
> AFAIK, the Zedboard has no CAN physical layer on - how did you turn your
> CAN Tx and Rx into CAN_H and CAN_L?
>
> The CAN checklist goes:
>
> * Have you got all the same "type" of PHY (there are high-speed,
> low-speed, single-wire etc. variants)
>
> * If high-speed, is the bus using twisted pair wiring?
>
> * Is the bus a sensible length ("sensible" depends on bit-rate, wire
> quality, and sundry other issues, so start with a small bus on the
> bench ~2m)
>
> * Is the bus terminated correctly?
>
> * Have you another node on the bus to acknowledge the transmissions?
>
> * Are all the nodes running with the same bit width and sampling point?
>
> * Is the bus noise-free?
>
> Do you have any CAN analysis tools (Canalyzer for example, or a
> scope/logic analyser that understands the protocol)?
>
> Cheers,
> Martin
>
Sorry I didn't check the forum for a long time.
In the mean time I solved all the problems.
can4linux is working now on the ZedBoard.
The CAN transceivers are on an FMC board, called ISM
http://www.em.avnet.com/en-us/design/drc/Pages/ISM-Networking-FMC-
Module.aspx
Regards
Heinz
Article: 154928rickman wrote: > On 2/15/2013 12:59 PM, RCIngham wrote: >> Does anyone know why ModelSim version numbers skipped from 6.6 to 10, >> missing out 7, 8,and 9? >> >> Thanks in anticipation. > > It might have something to do with the rumor that Microsoft has patented > the numbers 7, 8 and 9. They would have patented 1 through 6 but Apple > beat them to it. > > Hmmm... I wonder if anyone has patented 11 yet... better yet, just > patent all the real numbers in one swell foop! But please exclude the > transcendentals, there's no justification for patenting pi. :( > I'm pretty sure that Spinal Tap has patented the number 11 ;-) "Ours goes to eleven!" -- GaborArticle: 154929
Hi.. am supposed to implement a 8051 open core into a spartan 3e board and = verify the implementation with led blink program.. i have implemented the c= ore into the fpga successfully...=20 What I have to do now is to load the blink program into the program memory = of the 8051... so i need to program this code into the block ram... for tha= t am supposed to generate .mem and .bmm file which can be handled with data= 2mem software.. The problem which i face is I have absolutely no idea about generating a .m= em or .bmm file... though i saw many links online for reference no one has = given a clear idea about how to generate it... it will be very helpful if s= omeone tells me how to do it step by step... Thanks a lot!!=20 CheersArticle: 154930
On 19.02.2013 13:41, atlantic_pure wrote: > Hi.. am supposed to implement a 8051 open core into a spartan 3e board and verify the > implementation with led blink program.. i have implemented the core into the fpga successfully... > > What I have to do now is to load the blink program into the program memory of the > 8051... so i need to program this code into the block ram... for that am supposed > to generate .mem and .bmm file which can be handled with data2mem software.. > > The problem which i face is I have absolutely no idea about generating a .mem > or .bmm file... though i saw many links online for reference no one has given a > clear idea about how to generate it... it will be very helpful if someone tells > me how to do it step by step... http://www.bitlib.de/pub/mproz/mproz3.zip is a step-by-step tutorial for a very simple processor implemented on a Spartan 3e using block ram as program memory.Article: 154931
Thank you so much for the zip file... Am programming 8051 in verilog... can i use the same files for verilog as well?? thanks!! On Tuesday, February 19, 2013 5:15:51 PM UTC+1, Herbert Kleebauer wrote: > On 19.02.2013 13:41, atlantic_pure wrote: > > > Hi.. am supposed to implement a 8051 open core into a spartan 3e board and verify the > > > implementation with led blink program.. i have implemented the core into the fpga successfully... > > > > > > What I have to do now is to load the blink program into the program memory of the > > > 8051... so i need to program this code into the block ram... for that am supposed > > > to generate .mem and .bmm file which can be handled with data2mem software.. > > > > > > The problem which i face is I have absolutely no idea about generating a .mem > > > or .bmm file... though i saw many links online for reference no one has given a > > > clear idea about how to generate it... it will be very helpful if someone tells > > > me how to do it step by step... > > > > > > http://www.bitlib.de/pub/mproz/mproz3.zip > > > > is a step-by-step tutorial for a very simple processor implemented > > on a Spartan 3e using block ram as program memory.Article: 154932
On 20.02.2013 05:04, atlantic_pure wrote: > Am programming 8051 in verilog... can i use the same files for verilog as well?? I always used schematic entry (a picture tells more than 100 lines of code), but as far as I remember, Xilinx software converted the schematic files to VHDL files, so you alway can look at the generated VDHL files. Modification of the BRAM content in the bit file is independent of the way the bit file was created (from schematics or VHDL/VERILOG).Article: 154933
Hi!! My Task: 1.I need to implement an INTEL 8051 core (Verilog) into a Xilinx Spartan 3E (xcs3500e) board. 2. After implementation, verify the board with led blink program.. I completed my task 1. I'm left out with task 2!! My question is how can I load the blink program into the device?? This blink program acts as the final verification for my implementation!! Experts kindly help me Thank a TON!Article: 154934
On Saturday, November 17, 2012 7:55:00 PM UTC-5, fl wrote:
> Hi,
>
>
>
> I know some VHDL, but totally new to verilog. Now I am reading a verilog template. I do not know the meaning of the following code:
>
>
>
> assign ce_hciccomp_decode = (cur_count == 0 && clk_enable == 1'b1)? 1 :
>
> (cur_count == 2 && clk_enable == 1'b1)? 1 :
>
> ...
Another alternative for rewriting this more clearly is to use the Verilog 'inside' operator (now supported by Synplify):
assign ce_hciccomp_decode = clk_enable && cur_count inside {0,2,4,7,10,...61};
-Kevin
Article: 154935
always @(negedge nrst or posedge PCLK or negedge begin)
begin
...
end
So,how can i determine what event does really happen in begin end block??
Article: 154936On 2/23/2013 8:38 AM, yu zhou wrote: > always @(negedge nrst or posedge PCLK or negedge begin) > begin > ... > end > > So,how can i determine what event does really happen in begin end block?? > You can't. You can only test the current state of the variables in the sensitivity list. Luckily this isn't generally necessary for common synthesis constructs, and my guess is that anything with more than two edge events in the sensitivity list won't synthesize. For simulation, you would typically work around this by using multiple processes, since you don't have the same constraint of driving a signal from only one process like you would for synthesis. -- GaborArticle: 154937
sir i need vhdl code for viterbi decoder please snd me the code sirArticle: 154938
<fabtn2012@gmail.com> wrote in message news:0f2a1599-33da-4185-84ca-fca384618c30@googlegroups.com... > sir i need vhdl code for viterbi decoder please snd me the code sir Sure no problem. Please make check out for £2350 + Vat.Article: 154939
On Saturday, February 23, 2013 5:38:40 AM UTC-8, yu zhou wrote: > always @(negedge nrst or posedge PCLK or negedge begin) > ... > So,how can i determine what event does really happen in begin end block?? First of all begin is a reserved verilog keyword so "negedge begin" is goin= g to give you heartache; change the identifier. Secondly if you want to synthesize this, you have to check if your target l= ibrary supports two asynchronous inputs simultaneously. Some (asic) librari= es have async set & reset flops so, it might synthesize if you write "if (!= nrst) foo <=3D 0; if (!brst) foo <=3D 1;" etc. But to get the right behavio= r, you have to follow the (set/reset) priority of your library flop to get = the simulation behavior to match it. Lastly if you are just trying to get it to simulate it, you can write some = complicated case/if-else statements to check the state of every variable to= see which event has actually fired but you should realize that there is no= way this will be synthesis friendly.Article: 154940
muzaffer.kal@gmail.com wrote: > On Saturday, February 23, 2013 5:38:40 AM UTC-8, yu zhou wrote: >> always @(negedge nrst or posedge PCLK or negedge begin) >> ... >> So,how can i determine what event does really happen in begin end block?? > > First of all begin is a reserved verilog keyword so "negedge begin" is going to give you heartache; change the identifier. > > Secondly if you want to synthesize this, you have to check if your target library supports two asynchronous inputs simultaneously. Some (asic) libraries have async set & reset flops so, it might synthesize if you write "if (!nrst) foo <= 0; if (!brst) foo <= 1;" etc. But to get the right behavior, you have to follow the (set/reset) priority of your library flop to get the simulation behavior to match it. > > Lastly if you are just trying to get it to simulate it, you can write some complicated case/if-else statements to check the state of every variable to see which event has actually fired but you should realize that there is no way this will be synthesis friendly. The point I was making is that even with if/else logic, you can't always tell which event triggered the process, because there may be more than one signal which is in the state it would be if it had just triggered the process. You might be able to detect the event if you also kept track of the previous state of each variable, but the process won't do this for you, so you would need more registers for this. For simulation, it is more typical to use multiple processes to describe a flop with multiple asynchronous controls. Also note that to describe for example a D FF with async set and reset, you really need to be sensitive to both edges of the set and reset inputs to handle the case where both were asserted at the same time and then one of them released. I don't know of any synthesizers that allow you to infer this sort of flop, so I've always instantiated them if necessary. -- GaborArticle: 154941
On Sun, 24 Feb 2013 16:24:28 +0000, Andy Bartlett wrote: > <fabtn2012@gmail.com> wrote in message > news:0f2a1599-33da-4185-84ca-fca384618c30@googlegroups.com... >> sir i need vhdl code for viterbi decoder please snd me the code sir > > Sure no problem. Please make check out for £2350 + Vat. One does wonder just what people think is on the other end of the conversation in a newsgroup. Like Andy, I'm not going to work for free, but I'll happily help you out if you contact me off-group, with money in hand. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.comArticle: 154942
yu zhou <zydgyy@gmail.com> wrote: > always @(negedge nrst or posedge PCLK or negedge begin) > begin > ... > end > So,how can i determine what event does really happen in begin > end block?? If you can't figure it out, how would the synthesis tool or actual FF figure it out? In a more usual case, you see something like: always @(posedge clk or posedge reset) begin if(reset) q <= 0; else q<=d; end (I might have that wrong, but maybe you see the idea.) If reset goes high, it resets. If reset is high on a clock positive edge, it stays reset. If reset is not high on a clock positive edge, it clocks data in. There are four cases here to consider. clk high or low on posedge reset, and reset high or low on posedge clk. (The tools usually don't know that there is the case that both change at once. In actual logic, it would usually be a setup/hold violation and/or race condition.) If you have three edge events, then you have to consider the state of the other two signals on any of the three events, for 12 combinations. Note the use of posedge reset, though the FF reset is not edge triggered. The only interesting thing happens on the posedge. The rest of the state has to depend on the current values of the other signals on the transition. (If reset is high, it stays reset even when a clk event occurs.) On the other hand: always @(posedge clk) begin if(reset) q <= 0; else q<=d; end generates a synchronous reset FF. -- glenArticle: 154943
Tim Wescott <tim@seemywebsite.com> wrote: > On Sun, 24 Feb 2013 16:24:28 +0000, Andy Bartlett wrote: >> <fabtn2012@gmail.com> wrote in message >> news:0f2a1599-33da-4185-84ca-fca384618c30@googlegroups.com... >>> sir i need vhdl code for viterbi decoder please snd me the code sir >> Sure no problem. Please make check out for £2350 + Vat. > One does wonder just what people think is on the other end of the > conversation in a newsgroup. > Like Andy, I'm not going to work for free, but I'll happily help you out > if you contact me off-group, with money in hand. It is certainly possible that one exists in, for example, opencores. In that case, if one did reply, it would usually be with the link to the site and not the actual code. Anyone remember the movie "Back to the Future" when the main character goes to a lunch counter and orders a "Pepsi Free" (which didn't yet exist)? -- glenArticle: 154944
On Mon, 25 Feb 2013 19:24:41 +0000, glen herrmannsfeldt wrote: > Tim Wescott <tim@seemywebsite.com> wrote: >> On Sun, 24 Feb 2013 16:24:28 +0000, Andy Bartlett wrote: > >>> <fabtn2012@gmail.com> wrote in message >>> news:0f2a1599-33da-4185-84ca-fca384618c30@googlegroups.com... >>>> sir i need vhdl code for viterbi decoder please snd me the code sir > >>> Sure no problem. Please make check out for £2350 + Vat. > >> One does wonder just what people think is on the other end of the >> conversation in a newsgroup. > >> Like Andy, I'm not going to work for free, but I'll happily help you >> out if you contact me off-group, with money in hand. > > It is certainly possible that one exists in, for example, opencores. > > In that case, if one did reply, it would usually be with the link to the > site and not the actual code. I should probably have pointed that out. "I need code, send it to me" just pushes a button with me, even though I know it's usually some student, possibly foreign, who is not being rude on purpose. Sigh. I suppose I could give up being a curmudgeon for Lent, but then where would I be? -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 154945
Folks, Anyone can share their experience with the Tek's FPGAview? + Go ahead buy it + Wait for updates + Don't bother Thx. SanjayArticle: 154946
On 2/25/2013 9:05 AM, GaborSzakacs wrote:
> muzaffer.kal@gmail.com wrote:
>> On Saturday, February 23, 2013 5:38:40 AM UTC-8, yu zhou wrote:
>>> always @(negedge nrst or posedge PCLK or negedge begin)
>>> ...
>>> So,how can i determine what event does really happen in begin end
>>> block??
>>
>> First of all begin is a reserved verilog keyword so "negedge begin" is
>> going to give you heartache; change the identifier.
>>
>> Secondly if you want to synthesize this, you have to check if your
>> target library supports two asynchronous inputs simultaneously. Some
>> (asic) libraries have async set & reset flops so, it might synthesize
>> if you write "if (!nrst) foo <= 0; if (!brst) foo <= 1;" etc. But to
>> get the right behavior, you have to follow the (set/reset) priority of
>> your library flop to get the simulation behavior to match it.
>>
>> Lastly if you are just trying to get it to simulate it, you can write
>> some complicated case/if-else statements to check the state of every
>> variable to see which event has actually fired but you should realize
>> that there is no way this will be synthesis friendly.
>
> The point I was making is that even with if/else logic,
> you can't always tell which event triggered the process,
> because there may be more than one signal which is in
> the state it would be if it had just triggered the process.
>
> You might be able to detect the event if you also kept track
> of the previous state of each variable, but the process
> won't do this for you, so you would need more registers
> for this.
This is different from VHDL. The signal keeps track of the current
state, the prior state and whether or not the state changed for this
delta cycle. rising_edge(foo) checks that foo is in the '1' state (or
'high' IIRC) and if the signal had just changed, foo'event=TRUE (or is
it '1', again, I don't recall). These conditions can all be checked in
the code using IF statements.
> For simulation, it is more typical to use multiple processes
> to describe a flop with multiple asynchronous controls. Also
> note that to describe for example a D FF with async set and reset,
> you really need to be sensitive to both edges of the set and
> reset inputs to handle the case where both were asserted at the
> same time and then one of them released. I don't know of
> any synthesizers that allow you to infer this sort of flop,
> so I've always instantiated them if necessary.
I don't follow what you mean. I'm not as familiar with Verilog. In
VHDL you would just include both the set and reset signal in the
sensitivity list which runs the process anytime any of those signals
change state. Then in the logic the states are checked to describe what
the logic should do about it. Sometimes that will be nothing, for
example on the falling edge of the rising edge sensitive clock signal.
The process will be activated by the falling edge, but the code will not
execute any assignments.
A D FF with both set and reset async inputs is not hard to describe in
VHDL. I can't imagine this is hard to describe in Verilog either. I
don't understand what you mean by "I don't know of any synthesizers that
allow you to infer this sort of flop". Is that really a limitation in
Verilog?
process(Clk, Reset, Set) begin
if (Reset) then
Q <= '0';
elsif (Set) then
Q <= '1';
elsif (rising_edge(Clk)) then
Q <= Dinput;
end if;
end process;
In this case the Reset input has priority over the Set which has
priority over the Clk. How do you do this in Verilog? I just realized
that I need to download a Verilog cheat sheet. I have a couple for
VHDL, but none for Verilog... my bad!
Wouldn't you just write...
always@(posedge Clk or Reset or Set)
if (Reset)...
--
Rick
Article: 154947On 2/25/2013 2:18 PM, glen herrmannsfeldt wrote: > yu zhou<zydgyy@gmail.com> wrote: >> always @(negedge nrst or posedge PCLK or negedge begin) >> begin >> ... >> end > >> So,how can i determine what event does really happen in begin >> end block?? > > If you can't figure it out, how would the synthesis tool or > actual FF figure it out? > > In a more usual case, you see something like: > > always @(posedge clk or posedge reset) begin > if(reset) q<= 0; > else q<=d; > end > > (I might have that wrong, but maybe you see the idea.) > > If reset goes high, it resets. > > If reset is high on a clock positive edge, it stays reset. > > If reset is not high on a clock positive edge, it clocks data in. > > There are four cases here to consider. clk high or low on > posedge reset, and reset high or low on posedge clk. > > (The tools usually don't know that there is the case that > both change at once. In actual logic, it would usually be > a setup/hold violation and/or race condition.) > > If you have three edge events, then you have to consider the > state of the other two signals on any of the three events, > for 12 combinations. > > Note the use of posedge reset, though the FF reset is not edge > triggered. The only interesting thing happens on the posedge. > The rest of the state has to depend on the current values of the > other signals on the transition. (If reset is high, it stays reset > even when a clk event occurs.) Yes, that is the part I'm not clear on. What if the simulation starts with reset at '1'. Is an event generated on reset anyway so that the process runs and q is reset? -- RickArticle: 154948
rickman wrote:
> On 2/25/2013 9:05 AM, GaborSzakacs wrote:
>> muzaffer.kal@gmail.com wrote:
>>> On Saturday, February 23, 2013 5:38:40 AM UTC-8, yu zhou wrote:
>>>> always @(negedge nrst or posedge PCLK or negedge begin)
>>>> ...
>>>> So,how can i determine what event does really happen in begin end
>>>> block??
>>>
>>> First of all begin is a reserved verilog keyword so "negedge begin" is
>>> going to give you heartache; change the identifier.
>>>
>>> Secondly if you want to synthesize this, you have to check if your
>>> target library supports two asynchronous inputs simultaneously. Some
>>> (asic) libraries have async set & reset flops so, it might synthesize
>>> if you write "if (!nrst) foo <= 0; if (!brst) foo <= 1;" etc. But to
>>> get the right behavior, you have to follow the (set/reset) priority of
>>> your library flop to get the simulation behavior to match it.
>>>
>>> Lastly if you are just trying to get it to simulate it, you can write
>>> some complicated case/if-else statements to check the state of every
>>> variable to see which event has actually fired but you should realize
>>> that there is no way this will be synthesis friendly.
>>
>> The point I was making is that even with if/else logic,
>> you can't always tell which event triggered the process,
>> because there may be more than one signal which is in
>> the state it would be if it had just triggered the process.
>>
>> You might be able to detect the event if you also kept track
>> of the previous state of each variable, but the process
>> won't do this for you, so you would need more registers
>> for this.
>
> This is different from VHDL. The signal keeps track of the current
> state, the prior state and whether or not the state changed for this
> delta cycle. rising_edge(foo) checks that foo is in the '1' state (or
> 'high' IIRC) and if the signal had just changed, foo'event=TRUE (or is
> it '1', again, I don't recall). These conditions can all be checked in
> the code using IF statements.
>
>
>> For simulation, it is more typical to use multiple processes
>> to describe a flop with multiple asynchronous controls. Also
>> note that to describe for example a D FF with async set and reset,
>> you really need to be sensitive to both edges of the set and
>> reset inputs to handle the case where both were asserted at the
>> same time and then one of them released. I don't know of
>> any synthesizers that allow you to infer this sort of flop,
>> so I've always instantiated them if necessary.
>
> I don't follow what you mean. I'm not as familiar with Verilog. In
> VHDL you would just include both the set and reset signal in the
> sensitivity list which runs the process anytime any of those signals
> change state. Then in the logic the states are checked to describe what
> the logic should do about it. Sometimes that will be nothing, for
> example on the falling edge of the rising edge sensitive clock signal.
> The process will be activated by the falling edge, but the code will not
> execute any assignments.
>
> A D FF with both set and reset async inputs is not hard to describe in
> VHDL. I can't imagine this is hard to describe in Verilog either. I
> don't understand what you mean by "I don't know of any synthesizers that
> allow you to infer this sort of flop". Is that really a limitation in
> Verilog?
>
> process(Clk, Reset, Set) begin
> if (Reset) then
> Q <= '0';
> elsif (Set) then
> Q <= '1';
> elsif (rising_edge(Clk)) then
> Q <= Dinput;
> end if;
> end process;
>
> In this case the Reset input has priority over the Set which has
> priority over the Clk. How do you do this in Verilog? I just realized
> that I need to download a Verilog cheat sheet. I have a couple for
> VHDL, but none for Verilog... my bad!
>
> Wouldn't you just write...
>
> always@(posedge Clk or Reset or Set)
> if (Reset)...
>
The problem in Verilog is that you can't place the edge dependancy
in the if statements within the always block. A clocked block in
Verilog has the edge dependencies in the sensitivity list itself
and you use the if statement to check the current (post event) state
of the signals. So you don't really have the equivalent of the VHDL
code where the if statements for the set/reset are level triggered
but the if statement for the clock is edge triggered. There was a
prolonged discussion of this in comp.lang.verilog where the bottom
line was that you need two processes to properly describe a D-FF
with two asynchronous controls.
Regarding your suggestion, the block would trigger on either
edge of set or reset, and only on the rising edge of clk. Now
if you wrote:
always @ (posedge clk or reset or set)
if (reset)
Q <= 0;
else if (set) Q <= 1;
else Q <= D;
Then the problem is that the final else cannot really check that you
got here because of the rising clock edge. You could add:
else if (clk) Q <= D;
But even that would not work in the case where you released the
last asynchronous input while the clock was already high. And
since you don't get to this point until after the event that
triggered the block, you can't say else @ (posedge clk) Q <= D;
because that would say to wait for another rising edge.
Bottom line, for Verilog to model this properly you need two processes:
always @ (set or reset)
if (reset) Q = 0;
else if (set) Q = 1;
always @ (posedge clk)
Q <= D;
Which works fine for simulation, but gives you a "multisource" error
for synthesis.
-- Gabor
Article: 154949rickman wrote: > On 2/25/2013 2:18 PM, glen herrmannsfeldt wrote: >> yu zhou<zydgyy@gmail.com> wrote: >>> always @(negedge nrst or posedge PCLK or negedge begin) >>> begin >>> ... >>> end >> >>> So,how can i determine what event does really happen in begin >>> end block?? >> >> If you can't figure it out, how would the synthesis tool or >> actual FF figure it out? >> >> In a more usual case, you see something like: >> >> always @(posedge clk or posedge reset) begin >> if(reset) q<= 0; >> else q<=d; >> end >> >> (I might have that wrong, but maybe you see the idea.) >> >> If reset goes high, it resets. >> >> If reset is high on a clock positive edge, it stays reset. >> >> If reset is not high on a clock positive edge, it clocks data in. >> >> There are four cases here to consider. clk high or low on >> posedge reset, and reset high or low on posedge clk. >> >> (The tools usually don't know that there is the case that >> both change at once. In actual logic, it would usually be >> a setup/hold violation and/or race condition.) >> >> If you have three edge events, then you have to consider the >> state of the other two signals on any of the three events, >> for 12 combinations. >> >> Note the use of posedge reset, though the FF reset is not edge >> triggered. The only interesting thing happens on the posedge. >> The rest of the state has to depend on the current values of the >> other signals on the transition. (If reset is high, it stays reset >> even when a clk event occurs.) > > Yes, that is the part I'm not clear on. What if the simulation starts > with reset at '1'. Is an event generated on reset anyway so that the > process runs and q is reset? > The simulation always starts with everything undriven. So initial statements at time zero, or initial values in a reg declaration will always create an edge. Thus I typically start my simulation with: initial begin reset = 1; clk = 0; . . . #100 reset = 0; . . . end And all of my asynchronous reset processes trigger at time zero. Note that a clock is typically initialized to zero which would trigger any negedge processes at time zero as well. -- Gabor
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z