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 May 27, 1:42=A0am, marts...@gmail.com wrote: > On May 27, 12:25 am, Thomas Stanka <usenet_nospam_va...@stanka-web.de> > wrote: > > > > > > > On 27 Mai, 05:18, marts...@gmail.com wrote: > > > > signal x: std_logic; > > > > you don't assign any value to "x" > > [..] > > > how does the x power up? high/low?? is that part/technology dependent?= > > > > the reason I am asking this is because, I have a part that used to > > > work all the time but now I got a different part (same mfg), > > > programmed with the same programming file and it seems like x is > > > powering up differently. > > > Try a Reset on Power up. > > For most FPGAs there is a global value for Powerup content that is > > valid before you use a reset. > > First of all, inspect the synthesis result. Only latches and FF are > > set during power up. All other signals depend on the contentg of > > Inputs, FF and latches. > > > bye Thomas > > Thomas, > > Thanks for your input. But what I was trying to figure out is > that...If I am not using the reset, or not assign any values to > signal, what happens in that case? I do know how to fix it but I was > just curious to find out, why was this working for sometime but now > doesn't work with a different part (same mfg)? > Thanks, > Martin- Hide quoted text - > =46rom the synthesis tool's perspective, the lack of any assignment to 'x' in the source code means that it is free to assign anything to 'x'. Furthermore, because 'y' depends on 'x' it means that the synthesis tool is free to assign anything to 'y' as well. There are five possibilities: 1. x set to '0' which implies that y will be assigned '0' as well. 2. x set to '1' which implies that y will be assigned '1' as well. 3. x connected to some existing signal in the design, which implies that y will track that signal as well. 4. y connected to some existing signal in the design. 5. y set to 'Z'. If the synthesis tool chose #1 or #2, you wouldn't see any difference in the observable output 'y' as you change parts. Since that is not what you're observing it would rule out these choices. If it implemented choice #3 or #4 then you'd have to back track further to see what is the power up state of the signal that it chose to connect to 'y'. If it implemented choice #5 it might appear to power up differently with a different part because you'd be trying to discern a logic level from a signal that is not being actively driven. In any case, the answer to your question lies in the equations file that was output from place and route. Take a look for the equations for output 'y' and the answer to the mystery will (most likely) be solved. Kevin JenningsArticle: 132476
On May 28, 11:24=A0am, Brian Philofsky <brian.philofsky@no_xilinx_span.com> wrote: > KJ wrote: > > On May 28, 6:50 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > > This very well could be a timing issue but another possible cause of > this could be the writing of simulatable code but not synthesizable > code. =A0Looking at the code, I see the signals a and b in the sensitivity= > list of the process which could cause the else statement to get > evaluated asynchronously in simulation however for synthesis, the > sensitivity list is likely ignored (generally with a warning) and thus > processed differently. =A0 Having 'a' and 'b' in the sensitivity list is not the problem. The structure of the code is process(...) begin if (rst =3D '1') then ...assignements here elsif (clk'event and clk =3D '1') then ...assignements here end if; end process; There are no assignments to anything outside of the if statement. That if statement is of the form for flops with async presets/resets. Having 'extra' signals in the sensitivity list will not result in any difference between simulation and synthesis. If it does, then contact the synthesis tool provider and submit a bug report. KJ I suggest removing the a and b signals from the > sensitivity list and see if the behavioral simulation still works. =A0My > guess is that may reveal your issue however if that does not, then I do > suggest looking more closely at the synthesis logs as well as timing > analysis to ensure it is not another synthesis mis-match issue or timing > issue. > > >> In general, is it always this difficult and fraught with peril? I write= > >> =A0>2000 lines/month in C++ with only minor misspelling mishaps. These = 50 lines > >> have caused me more gray hairs than many whole systems. > > > Hardware design (even if written in a software like language such as > > VHDL or Verilog) is not the same as software. =A0You can be well skilled= > > in the one discipline and at the same time be unskilled in the other. > > It is all what you are used to. =A0I can not write C++ worth a lick so it > would likely take me a long time to write a program using it however I > feel I am very proficient with VHDL and Verilog. > > >> Also, is there a way to tell XST to not treat reset as a clock? I haven= 't > >> fully read up on configuration, having spent way too much time on this > >> little time waster. > > > What makes you think that it is using reset as a clock? > > I imagine you are referring to XST using a global buffer for the reset > signal. =A0In general this should not cause any issues and many times can > be the right thing to do but if you want to go to prevent that behavior, > tell XST you want an IBUF on the reset signal by adding the following > attribute: > > attribute BUFFER_TYPE : string; > attribute BUFFER_TYPE of rst: signal is "IBUF"; > > This will force it to use a regular I/O instead of a global buffer. > > Hope this helps and do not get too discouraged. =A0If you are just > learning, I could also suggest you try Verilog over VHDL. =A0I am not > trying to start the holy wars of languages but many do feel it is less > of a leap from C to Verilog than VHDL. =A0Again, I am not trying to start > a language debate so please leave do not let my statement start one. > > -- =A0Brian > > > > >> Last, .... is this really worth pursuing? I've been programming for 25 > >> years, and know that the greatest leassons come after the greatest pain= . But > >> there's also good pain, and just senseless injury. Is this not a suitab= le > >> first Zen parable to contemplate? I'm goaded forward by the belief that= > >> there's a good lesson on synchronous systems lurking as the punchline. > > > The punchline might be static timing analysis. =A0Signals don't just > > 'happen' when you want them to, you need to guarantee by design that > > they arrive at the proper time relative to the clock. > > > Kevin Jennings- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text -Article: 132477
I run Xilinx ISE v10.1 and use VHDL. I have put together a fairly small circuit that merely sends out solid colors and sync signals on a VGA line. During the active video portion of time, a color should show up on the screen. The color depends on which of three switches on my development board are turned on. There is one for red, green and blue. Now the behavioral simulation tells me that the code works exactly as it is supposed to, however, when I actually implement it on my development board it does not work. I have heard of this type of problem many times, but have no idea where to begin in finding the fault. Just so nobody thinks I'm trying too much at once, I did try it without the switches and told it to just output a solid, unchanging, color. That worked. I tested it for each of the three colors. The RTL schematic that is generated by ISE shows me that both the three switches and the red_out, green_out, and blue_out do not exist, but none of the warning messages that show up tell me that they were removed. Can somebody tell me where to begin in solving this issue? Perhaps a list of things to try / look for or link me to some possible solution or list of solutions.Article: 132478
"KJ" <kkjennings@sbcglobal.net> wrote in message news:148a2566-df59-4dc1-9644-f231a378a9eb@t54g2000hsg.googlegroups.com... On May 28, 6:50 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > Sorry, Guys. We're not quite done yet with the quadrature encoder. I tried > to rewrite it as a synchronous process. The behavioral sim shows it > working > as intended. The post-route sim and onboard test don't work. 'debouncing' > never changes state in the sim. The leds don't sequence when I twist the > magic knob. > This is always a symptom of a timing problem. In your particular case I suspect the timing of 'a' and 'b' relative to clk is not meeting the setup/hold time requirements of the device (from your report file). The signals 'a' and 'b' should be brought into only one flop, the output of that flop should be fed into a second flop, the output of that second flop can then be reliably used wherever you currently have 'a' and 'b'. =================== 'a' and 'b' are driven by a hand turned rotary encoder. I tried buffering them into flops with concurrent statements, a_next and b_next, and used a_next and b_next internally. This caused 'a' and 'b' to not get routed at all, along with all logic associated with them. The circuit was reduced to only those parts lighting the leds. >>>>>>>>>>>>>> > Also, is there a way to tell XST to not treat reset as a clock? I haven't > fully read up on configuration, having spent way too much time on this > little time waster. What makes you think that it is using reset as a clock? ====== The synthesis report: Number of GCLKs: 2 out of 24 8% ... Clock Information: ------------------ -----------------------------------+------------------------+-------+ Clock Signal | Clock buffer(FF name) | Load | -----------------------------------+------------------------+-------+ sys_rst_pin | IBUF+BUFG | 1 | sys_clk_pin | BUFGP | 7 | -----------------------------------+------------------------+-------+ Asynchronous Control Signals Information: ---------------------------------------- -------------------------------------------------------------+---------------------------+-------+ Control Signal | Buffer(FF name) | Load | -------------------------------------------------------------+---------------------------+-------+ sys_rst_pin | IBUF | 5 | Inst_q_decode/a_prev_and0000(Inst_q_decode/a_prev_and00001:O)| NONE(Inst_q_decode/b_prev)| 2 | Inst_q_decode/a_prev_and0001(Inst_q_decode/a_prev_and00011:O)| NONE(Inst_q_decode/b_prev)| 2 | -------------------------------------------------------------+---------------------------+-------+ I suppose if I understood what that said, a_prev_andxxxxx are the cause of my difficulties.Article: 132479
Try a gate-level simulation and see what is going on. Are you sure there are no warning messages? Cheers, JonArticle: 132480
I have a design on FPGA that is ready. However, we need to have some mapping from fpga design to asic. I know that this will not be accurate. But accuracy is not our concern right now. We just need upper bound. Also, we are also looking for some IP Core for ASIC so that we can rough estimate. Regards, Vijayant On May 24, 5:47=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Mike Lewis wrote: > > (snip) > > >>The traditional method for ASIC is to divide the number > >>of transistors by the number of transistors in a 2 input > >>NAND gate. =A0For CMOS, that is four. > > (snip) > > > What is your method for determining how many transistors are in the desi= gn? > > My synthesis tools only give me area. > > Last I knew, they gave transistors, but that was some time ago. > > For FPGA it is much harder to give a reliable count, and > you are asking in an FPGA newsgroup. > > If it gives gate counts different types of gates and with a > little guessing on transistors/gate. =A0 Is this for standard > cell, sea of gates, or something else? =A0I thought I used to > have pretty detailed information on the standard cell libraries, > including transistors for each library element. > > -- glenArticle: 132481
jared.pierce@gmail.com wrote:
> The RTL schematic that is generated by ISE shows me that both the
> three switches and the red_out, green_out, and blue_out do not exist,
There's your problem.
No registers are being inferred.
Are you using a synchronous process?
-- Mike Treseler
Article: 132482
"rickman" <gnuarm@gmail.com> wrote in message
news:357b1d3e-c34e-4ee0-be9d-cb681a4960e3@8g2000hse.googlegroups.com...
> Instead of posting code and asking us to look at it, why don't you
> debug the simulation??? That is what simulations are for. If you
> said it worked in pre and post layout simulation, but failed on real
> hardware, then it would be a sticky problem that could justify asking
> help. But if it is failing in simulation, you can dig in and see
> exactly why it is failing.
A fair comment; I often give similar advice.
I removed the rst handling, and now it simulates post-route, but still fails
in hardware. Could it be the ports? They're configured LVTTL with PULLDOWN.
The encoder switches are normally-open, grounded, and pulled to VCC when
they close.
> I am very surprised that this is working in pre-layout sim and failing
> in post. That is usually a timing problem and I can't imagine that
> you have any timing problems. Although the synchronization issue that
> KJ mentioned is very valid.
What's really troubling is that something so apparently simple can be
unstable. I wasn't asking for debug help so much, but help identifying what
constructs are stable when synthesized and which are prone for trouble. I
also wasn't expecting trouble.
The synthesis report now says this: "No asynchronous control signals found
in this design." The only change was to remove rst.
Examining the post-route sim gives no hint where it can be going wrong, or
what might be borderline. Debounce is a flipflop with clock-enable,
presumably gated to flop state appropriately. I was concerned about the c-e
relationship to storing the state for comparison in the next clock cycle,
but assignment to a_prev and b_prev occur after the clock-enable. It all
looks as intended.
> To simplify reading your code you might want to break out the
> different functions. Debounce is normally something done separate
> from the state machine you are implementing. So put it in a separate
> process and use a separate signal to drive the decoder process. Then
> you have a nice clean signal you can look at to see if the debounce
> process is working correctly.
It turns out that debouncing _is_ the state machine. It drives the counter
up or down 1 count, which in turn drives the lookup decoder. It was easier,
and I thought just as clear, to write the single line increment/decrement
inline.
>
> I am also not too sure of your decoder algorithm. It is a bit hard to
> read because of the number of indents and the formatting in this
> forum, but it looks like nothing is done with b transitions unless
> they are preceded by an a transition. I don't think that is an
> optimal approach for a decoder, but maybe this is because you want to
> handle higher speeds. But if you are getting transitions faster than
> the bounce settles, I don't think the encoder can be decoded. So none
> of this is clear to me.
On the clock rising edge:
Check for state change on 'a' if we're not debouncing.
If 'a' changed state, ignore further changes (debouncing).
If the change is a rising edge on 'a',
'b' is the direction of movement.
Increment or decrement the count accordingly.
Otherwise, we're already debouncing.
Clear debounce on the next 'b' change.
It would be more clear to restructure it explicitly as a FSM with the 2
states. I will do so.
Article: 132483In the Xilinx Virtex 4 architecture, does anyone know when you instantiate a FIFO using the FIFO16 blocks does the FIFO use the RAMB16 block next to it for its memory, or does the FIFO16 has its own dedicated memory (thus leaving the RAMB16 free for other uses)?Article: 132484
On May 28, 1:12=A0pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > "rickman" <gnu...@gmail.com> wrote in message > > news:357b1d3e-c34e-4ee0-be9d-cb681a4960e3@8g2000hse.googlegroups.com... > > > Instead of posting code and asking us to look at it, why don't you > > debug the simulation??? =A0That is what simulations are for. =A0If you > > said it worked in pre and post layout simulation, but failed on real > > hardware, then it would be a sticky problem that could justify asking > > help. =A0But if it is failing in simulation, you can dig in and see > > exactly why it is failing. > > A fair comment; I often give similar advice. > > I removed the rst handling, and now it simulates post-route, but still fai= ls > in hardware. Could it be the ports? They're configured LVTTL with PULLDOWN= . > The encoder switches are normally-open, grounded, and pulled to VCC when > they close. > > > I am very surprised that this is working in pre-layout sim and failing > > in post. =A0That is usually a timing problem and I can't imagine that > > you have any timing problems. =A0Although the synchronization issue that= > > KJ mentioned is very valid. > > What's really troubling is that something so apparently simple can be > unstable. I wasn't asking for debug help so much, but help identifying wha= t > constructs are stable when synthesized and which are prone for trouble. I > also wasn't expecting trouble. > > The synthesis report now says this: "No asynchronous control signals found= > in this design." The only change was to remove rst. > > Examining the post-route sim gives no hint where it can be going wrong, or= > what might be borderline. Debounce is a flipflop with clock-enable, > presumably gated to flop state appropriately. I was concerned about the c-= e > relationship to storing the state for comparison in the next clock cycle, > but assignment to a_prev and b_prev occur after the clock-enable. It all > looks as intended. > > > To simplify reading your code you might want to break out the > > different functions. =A0Debounce is normally something done separate > > from the state machine you are implementing. =A0So put it in a separate > > process and use a separate signal to drive the decoder process. Then > > you have a nice clean signal you can look at to see if the debounce > > process is working correctly. > > It turns out that debouncing _is_ the state machine. It drives the counter= > up or down 1 count, which in turn drives the lookup decoder. It was easier= , > and I thought just as clear, to write the single line increment/decrement > inline. > > > > > I am also not too sure of your decoder algorithm. =A0It is a bit hard to= > > read because of the number of indents and the formatting in this > > forum, but it looks like nothing is done with b transitions unless > > they are preceded by an a transition. =A0I don't think that is an > > optimal approach for a decoder, but maybe this is because you want to > > handle higher speeds. =A0But if you are getting transitions faster than > > the bounce settles, I don't think the encoder can be decoded. =A0So none= > > of this is clear to me. > > On the clock rising edge: > =A0 =A0 Check for state change on 'a' if we're not debouncing. > =A0 =A0 =A0 =A0 If 'a' changed state, ignore further changes (debouncing).= > =A0 =A0 =A0 =A0 If the change is a rising edge on 'a', > =A0 =A0 =A0 =A0 =A0 =A0 'b' is the direction of movement. > =A0 =A0 =A0 =A0 =A0 =A0 Increment or decrement the count accordingly. > =A0 =A0 Otherwise, we're already debouncing. > =A0 =A0 =A0 =A0 Clear debounce on the next 'b' change. > > It would be more clear to restructure it explicitly as a FSM with the 2 > states. I will do so. Is somebody trying to re-invent the wheel? Haven't we been through this in a seemingly endless thread? Didn't I point out two perfect and compact solutions? How much effort do we intend to waste on such a clearly-defined non- problem ? Peter AlfkeArticle: 132485
Erik Anderson wrote: > In the Xilinx Virtex 4 architecture, does anyone know when you > instantiate a FIFO using the FIFO16 blocks does the FIFO use the > RAMB16 block next to it for its memory, or does the FIFO16 has its own > dedicated memory (thus leaving the RAMB16 free for other uses)? The FIFO16: http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/v4lsc/v4lsc0092_83.html uses dedicated logic to turn a BlockRAM into a FIFO, either synchronous or asyncronous. Using one of these large FIFOs will use a BlockRAM. Smaller FIFOs can be implemented in distributed logic, however, leveraging the Shift Register memory mode of the LUTs for the synchronous FIFO. Many synthesizers will imply shift registers properly if you design the synchronous FIFO to leverage the silicon properly. Async FIFOs are a little more difficult in distributed memory and must use the dual-port mode but can work beautifully for small FIFOs. So how large are you going for?Article: 132486
"Peter Alfke" <peter@xilinx.com> wrote in message news:e3a18ba3-db21-498c-840a-3b36ce73246f@u12g2000prd.googlegroups.com... > Is somebody trying to re-invent the wheel? Most likely...but also most likely not in order to invent a better wheel but to learn. > Haven't we been through this in a seemingly endless thread? Yes > Didn't I point out two perfect and compact solutions? Others posted solutions as well, don't take all the credit. > How much effort do we intend to waste on such a clearly-defined non- > problem ? If you feel that you're wasting your time, then perhaps you should choose not to do that. KJArticle: 132487
Problem solved! Ist was really a stack/heap insufficiency combined with a very little programming error (Forgot a wait condition related to the Xilinx IIC driver) that caused my design go mad. Now everything seems to be fine. Thanks again, Philipp :-)Article: 132488
"Peter Alfke" <peter@xilinx.com> wrote in message news:e3a18ba3-db21-498c-840a-3b36ce73246f@u12g2000prd.googlegroups.com... On May 28, 1:12 pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote: Is somebody trying to re-invent the wheel? Haven't we been through this in a seemingly endless thread? Didn't I point out two perfect and compact solutions? How much effort do we intend to waste on such a clearly-defined non- problem ? ========= It isn't so much the reinvention of the wheel, Peter, but learning to hammer and chisel the stone round. It should have been a short exercise, but there are timing conflicts where I expected none. Doesn't it behoove the student to find the flaws in his thinking and approach? I thank you for your elegant solution, which I have put away for later study. I don't know what I'm doing wrong, and why my solution is so susceptible to problems. Hence, the questions. Regards, Mike.Article: 132489
In article <OqSdnacY_bKfqqHVnZ2dnUVZ_tvinZ2d@lmi.net>, rgaddi@technologyhighland.com says... > krw wrote: > > Toolset: ISE/ModelSim_PE/VHDL > > > > I've been asked to modify one of my designs for another application > > so decided it was time to parameterize it as much of it as possible. > > I ran into a roadblock changing configuration of CoreGen devices, so > > was simply going to force the eventual user to go through the GUI > > for any modifications. Then I RTFM. ;-) > > > > In the Comparator V9.0 Product Specification there an example of > > direct instantiation (Page 7), which looks like it'll save me a lot > > of headaches. I can simply use the generics I already have to > > manipulate the core. My problem is that ISE doesn't find the > > comparator in the library. I've had the problem (with ModelSim) > > where the libraries change and I'm pointing to an old copy but I > > don't know where to tell ISE where the libraries are. I've always > > used the GUI to generate cores before, but I really like the idea of > > direct instantiation. I can make my designs far more flexible > > without a whole lot of work. Anyone with a cluestick? > > > > > > Any reason to not just infer the comparator? VHDL generics make this > sort of thing a breeze. Two things... First, I want to walk before running. I also need to manually instantiate BRAMs and it would be nice to ditch the GUI altogether. It would make managing mu libraries through various core releases much simpler. Perhaps it's no longer true, but I found that the LogicCore devices were better optimized than the ones that were inferred from HDL. For equality, I'd just infer the thing and be done with it. Long magnitude comparators can have significant delays. At least that's what I've found in the past. (UPDATE: I did a test and inferred the comparators and one level up, even and it still seemed to pass timing (10% buffer through PAR) with the widest compare I expect (32 bits). Perhaps I'll go this way for the comparator anyway. It's simpler.) I don't need generic for the inferred comparator (other than the ones describing the busses that are already there). ;-) -- KeithArticle: 132490
MikeWhy wrote: > > "KJ" <kkjennings@sbcglobal.net> wrote in message > news:148a2566-df59-4dc1-9644-f231a378a9eb@t54g2000hsg.googlegroups.com... > On May 28, 6:50 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > >> Sorry, Guys. We're not quite done yet with the quadrature encoder. I >> tried >> to rewrite it as a synchronous process. The behavioral sim shows it >> working >> as intended. The post-route sim and onboard test don't work. 'debouncing' >> never changes state in the sim. The leds don't sequence when I twist the >> magic knob. >> > > This is always a symptom of a timing problem. In your particular case > I suspect the timing of 'a' and 'b' relative to clk is not meeting the > setup/hold time requirements of the device (from your report file). > The signals 'a' and 'b' should be brought into only one flop, the > output of that flop should be fed into a second flop, the output of > that second flop can then be reliably used wherever you currently have > 'a' and 'b'. > > =================== > > 'a' and 'b' are driven by a hand turned rotary encoder. > > I tried buffering them into flops with concurrent statements, a_next and > b_next, and used a_next and b_next internally. This caused 'a' and 'b' > to not get routed at all, along with all logic associated with them. The > circuit was reduced to only those parts lighting the leds. Then your code must have been suspect. You should NEVER drive the Quad pins, into anything other than sampling FF's (unless you are trying an async design :) Only the outputs of sampled signals should be in your state flows. > >>>>>>>>>>>>>>> > > > >> Also, is there a way to tell XST to not treat reset as a clock? I haven't >> fully read up on configuration, having spent way too much time on this >> little time waster. > > > What makes you think that it is using reset as a clock? > > ====== > The synthesis report: > > Number of GCLKs: 2 out of 24 8% > > ... > > Clock Information: > ------------------ > -----------------------------------+------------------------+-------+ > Clock Signal | Clock buffer(FF name) | Load | > -----------------------------------+------------------------+-------+ > sys_rst_pin | IBUF+BUFG | 1 | > sys_clk_pin | BUFGP | 7 | > -----------------------------------+------------------------+-------+ > > Asynchronous Control Signals Information: > ---------------------------------------- > -------------------------------------------------------------+---------------------------+-------+ > > Control Signal | Buffer(FF > name) | Load | > -------------------------------------------------------------+---------------------------+-------+ > > sys_rst_pin | IBUF | > 5 | > Inst_q_decode/a_prev_and0000(Inst_q_decode/a_prev_and00001:O)| > NONE(Inst_q_decode/b_prev)| 2 | > Inst_q_decode/a_prev_and0001(Inst_q_decode/a_prev_and00011:O)| > NONE(Inst_q_decode/b_prev)| 2 | > -------------------------------------------------------------+---------------------------+-------+ > > > I suppose if I understood what that said, a_prev_andxxxxx are the cause > of my difficulties. Strange looking report, - Try re-targeting to a CPLD, and look at the report equations. CPLD reports are more readable as they have wider-and terms, and less tool generated nodes. So, they are a good way to make sure you, and the tools, are on the 'same page'! -jgArticle: 132491
MikeWhy wrote: > On the clock rising edge: > Check for state change on 'a' if we're not debouncing. > If 'a' changed state, ignore further changes (debouncing). > If the change is a rising edge on 'a', > 'b' is the direction of movement. > Increment or decrement the count accordingly. > Otherwise, we're already debouncing. > Clear debounce on the next 'b' change. > > It would be more clear to restructure it explicitly as a FSM with the 2 > states. I will do so. This only counts once per 4 quadrants, or one quarter of the possible count rate. I presume that was your intention ? -jgArticle: 132492
Mike Treseler wrote: > MikeWhy wrote: > >>Sorry, Guys. We're not quite done yet with the quadrature encoder. I >>tried to rewrite it as a synchronous process. The behavioral sim shows >>it working as intended. The post-route sim and onboard test don't work. >>'debouncing' never changes state in the sim. The leds don't sequence >>when I twist the magic knob. > > > I like Ray's process here: > http://groups.google.com/groups/search?q=quadrature+resolver+single+process > I've added an entity here: > http://mysite.verizon.net/miketreseler/quad_encode.vhd > RTL view looks good, but untested. To me, both examples look to have an error, in confusing an edge with a direction. See Peter/Ken's Tested example, for separate rotary_event, rotary_right code. -jgArticle: 132493
"MikeWhy" <boat042-nospam@yahoo.com> wrote in message
news:Rpg%j.1342$iM3.234@flpi150.ffdc.sbc.com...
>
> "KJ" <kkjennings@sbcglobal.net> wrote in message
> news:148a2566-df59-4dc1-9644-f231a378a9eb@t54g2000hsg.googlegroups.com...
> On May 28, 6:50 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>>> Sorry, Guys. We're not quite done yet with the quadrature encoder. I
>>> tried
>>> to rewrite it as a synchronous process. The behavioral sim shows it
>>> working
>>> as intended. The post-route sim and onboard test don't work.
>>> 'debouncing'
>>> never changes state in the sim. The leds don't sequence when I twist the
>>> magic knob.
>>
>>
>> This is always a symptom of a timing problem. In your particular case
>> I suspect the timing of 'a' and 'b' relative to clk is not meeting the
>> setup/hold time requirements of the device (from your report file).
>> The signals 'a' and 'b' should be brought into only one flop, the
>> output of that flop should be fed into a second flop, the output of
>> that second flop can then be reliably used wherever you currently have
>> 'a' and 'b'.
>
> ===================
>
> 'a' and 'b' are driven by a hand turned rotary encoder.
>
Timing analysis is not about how often things change, but when do they
change relative to whatever it is that samples them. You have three
asynchronous inputs to your design (rst, a, b). What that means is that if
I were to ask you when does rst change in relationship to the clock your
answer would be I dunno (or something more grammatically correct). The same
would be true for 'a' and 'b'.
The problem is you then use these signals directly as inputs into logic that
gets clocked. The propogation delay from the input pin through whatever
logic there is to EACH flip flop will be different so when the clock comes
along some of the flops will see the 'new' value others will miss it. On
the next clock cycle, since some of the flops may have changed state, the
net result of the logic may be different. That's why you need to
synchronize everything to the clock first and then only use the synchronized
signals. In your case, make some new signals like rst_sync, a_sync and
b_sync where you bring rst, a and b in and perform no logic at all, just
clock them into a flop (i.e. with a clocked process).
Now change your logic to use a_sync instead of 'a', b_sync instead of 'b'
and rst_sync instead of 'rst'. This means lines like this...
if (rst = '1') then
if (a /= a_prev) then
etc.
will change to this...
if (rst_sync = '1') then
if (a_sync /= a_prev) then
etc.
Make sure that the ONLY place you use 'rst', 'a', or 'b' is to generate
'rst_sync', 'a_sync' and 'b_sync'. Reset the temptation to violate this
anywhere for any reason.
Simulate and make sure things still function.
> I tried buffering them into flops with concurrent statements, a_next and
> b_next, and used a_next and b_next internally. This caused 'a' and 'b' to
> not get routed at all, along with all logic associated with them. The
> circuit was reduced to only those parts lighting the leds.
>
Well, for starters you can't buffer them into flops with concurrent
statements unless you did this.
rst_sync <= rst when rising_edge(clk)
Usually one would do it like this
process(clk)
begin
if rising_edge(clk) then
rst_sync <= rst;
end if;
end process;
You can of course simply add the "rst_sync <= rst;" statement to your
clocked process if you prefer inside the "elsif (clk'event and clk = '1')
then" portion.
Secondly, if things didn't get routed, it was because you didn't connect
something up properly. Had you simulated the design you would find that it
wasn't working either.
>>>>>>>>>>>>>>>
>
>
>
>> Also, is there a way to tell XST to not treat reset as a clock? I haven't
>> fully read up on configuration, having spent way too much time on this
>> little time waster.
>
> What makes you think that it is using reset as a clock?
>
> ======
> The synthesis report:
>
> Number of GCLKs: 2 out of 24 8%
>
> ...
>
> Clock Information:
> ------------------
> -----------------------------------+------------------------+-------+
> Clock Signal | Clock buffer(FF name) | Load |
> -----------------------------------+------------------------+-------+
> sys_rst_pin | IBUF+BUFG | 1 |
> sys_clk_pin | BUFGP | 7 |
> -----------------------------------+------------------------+-------+
>
This is not a concern. It is simply saying that it's using a buffer to
drive the reset signal because it has a lot of internal loads, just like the
clock does. It's unfortunate that it says 'clock buffer' when it means
something more like 'big honkin buffer that can drive a lot of loads'.
Kevin Jennings
Article: 132494On May 28, 12:10 pm, KJ <kkjenni...@sbcglobal.net> wrote: > On May 28, 11:24 am, Brian Philofsky > > <brian.philofsky@no_xilinx_span.com> wrote: > > KJ wrote: > > > On May 28, 6:50 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > > > This very well could be a timing issue but another possible cause of > > this could be the writing of simulatable code but not synthesizable > > code. Looking at the code, I see the signals a and b in the sensitivity > > list of the process which could cause the else statement to get > > evaluated asynchronously in simulation however for synthesis, the > > sensitivity list is likely ignored (generally with a warning) and thus > > processed differently. > > Having 'a' and 'b' in the sensitivity list is not the problem. The > structure of the code is > process(...) > begin > if (rst = '1') then > ...assignements here > elsif (clk'event and clk = '1') then > ...assignements here > end if; > end process; > > There are no assignments to anything outside of the if statement. > That if statement is of the form for flops with async presets/resets. > Having 'extra' signals in the sensitivity list will not result in any > difference between simulation and synthesis. If it does, then contact > the synthesis tool provider and submit a bug report. Not only is the a and b not a problem, the a in the sensitivity list is *required* for proper simulation unless the simulator has the smarts to fix problems with the sensitivity list. Notice that there are assignments in the if (rst ='1') clause that have a on the right hand side. Since this is not in the clocked portion of the process, this is a concurrent assignment and the process must run when either rst or a change. > > >> Also, is there a way to tell XST to not treat reset as a clock? I haven't > > >> fully read up on configuration, having spent way too much time on this > > >> little time waster. > > > I imagine you are referring to XST using a global buffer for the reset > > signal. In general this should not cause any issues and many times can > > be the right thing to do but if you want to go to prevent that behavior, > > tell XST you want an IBUF on the reset signal by adding the following > > attribute: If the reset signal is being run on a global clock line, it is because your code does not allow the GSR to be used (a global net dedicated to the reset function). You are resetting to a signal value instead of a fixed value, so the set/reset signals have to be brought out to the routing matrix to accommodate that. It is actually preferred to use the clock nets for such a reset since your reset likely has a high fanout and it will not be able to meet a fast timing spec any other way. This also saves a lot of routing resources if you have spare clock lines. > > >> Last, .... is this really worth pursuing? I've been programming for 25 > > >> years, and know that the greatest leassons come after the greatest pain. But > > >> there's also good pain, and just senseless injury. Is this not a suitable > > >> first Zen parable to contemplate? I'm goaded forward by the belief that > > >> there's a good lesson on synchronous systems lurking as the punchline. > > > > The punchline might be static timing analysis. Signals don't just > > > 'happen' when you want them to, you need to guarantee by design that > > > they arrive at the proper time relative to the clock. Can you say what your clock rate is? For the most part, speeds of below 25 MHz are pretty easy to meet. Speeds of 100 MHz are a lot tougher. Speeds in the middle depend on the logic and the density. As you get above about 70% or 80% full, it gets harder to meet faster timing. The one problem that most newbies have, especially if they come from a software orientation, is thinking of HDL as software. HDL stands for Hardware Description Language and that is how it works. It describes hardware. If you try to write it like software, you most likely won't care for the hardware that results, if it produces hardware at all. Every construct I write I picture in terms of the hardware it will generate as well as the behavior it has. RickArticle: 132495
On May 28, 8:39 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > MikeWhy wrote: > > On the clock rising edge: > > Check for state change on 'a' if we're not debouncing. > > If 'a' changed state, ignore further changes (debouncing). > > If the change is a rising edge on 'a', > > 'b' is the direction of movement. > > Increment or decrement the count accordingly. > > Otherwise, we're already debouncing. > > Clear debounce on the next 'b' change. > > > It would be more clear to restructure it explicitly as a FSM with the 2 > > states. I will do so. > > This only counts once per 4 quadrants, or one quarter of the possible > count rate. > I presume that was your intention ? Yeah, that was what I saw too. A quad decoded should be able to increment on *each* edge of each signal. Both rising and falling edges have meaning and the direction is always indicated by the combination of edge direction and state of the other signal. I see the best approach as two state machines. One is the debouncer of *each* signal, a and b which also produces outputs for "edge of" each signal. The other is the quad decoder that has to consider the inputs a, b, a edge and b edge. Your combined state machine seems awkward and I'm not even sure it works. If you turn past a rising edge on a, and then reverse, the same spot on the encoder will produce a falling edge on a which is ignored. It won't produce a rising edge on a until you turn it back half a cycle. If you don't reach that half a cycle before reversing again and pass the same rising edge of a it will count up a second time! This is just plain wrong! Consider that the decoder has to distinguish eight different combinations. There are four different points in time and two directions. a __1____2__++3++++4++__1____2__++3++++4++__1__ b __1__++2++++3++__4____1__++2++++3++__4____1__ View the above in a fixed width font. See how there are four distinguishable states? You need to detect the four states of the encoder. In any given state you will see a transition on one of the two signals. Which signal transitions tells you which direction you are headed. The point of a quad encoder is to make the presence and direction of changes clearly distinguishable. In fact, unless the bouncing is fast compared to your clock rate, you don't even need to debounce the encoder. If you get two rising edges and a falling edge between, it should count up twice and down once and automatically debounce! Do use a single FF for each signal a and b before you use them in the FSM. An async signal may be seen in different states by the multiple FFs in a FSM. That will result in very bad behavior. Metastability can also be an issue, but I expect this just won't be apparent in your case. Still, even passing the signal through one FF will virtually eliminate metastability for clock rates below 25 MHz unless you really push the logic. Metastability is removed by the slack time between FFs. I need to do my own work, but it is boring me at the moment. I'm just not quite interested enough to try to figure out the other problems in your code... :^( I was not in on the other thread I guess you started, but it looks like there was no shortage of suggestions of how to write this better. If you were here, I would be happy to discuss this with you, but writing is just not as much fun. (you wouldn't know by the length of this post...) Sometimes computer coding is a bit like writing (literary, that is). Trying to fix something that is inherently bad does not really teach anything. Instead there are times you need to toss out what you have done and consider the work of others. If someone has given you code or pseudo-code that should work, then you might want to try implementing that. I bet when you have something that works and you understand it, you can better see the issues with your code. RickArticle: 132496
Thanks for the help guys. I made several changes and the problem finally went away. It works! I still don't know why it wasn't working so I plan to back up what I have and insert one test problem at a time to see what happens(of the problems I fixed). I still don't get why the RTL schematic would bother to include a DFF where the Q wasn't connected to anything. It would have been just as good not to include it. Any hints on that one?Article: 132497
Now that I have looked at it, this seems so frigging simple that I am
going to try to write it on the fly!
right_way : process (clk, rst) begin
if (rst = '1') then
old_a <= '0';
old_b <= '0';
older_a <= '0';
older_b <= '0';
count <= "0101";
elsif (rising_edge(clk)) then
if (old_a /= older_a or old_b /= older_b) then -- detect an edge
case ((older_a, older_b)) is -- not sure if this aggregate is
valid, you may need to make an assignment in the concurrent section
when ("00") => if (old_a = '1') then count = count-1; else
count=count+1; end if; -- state 1
when ("01") => if (old_a = '1') then count = count+1; else
count=count-1; end if; -- state 2
when ("11") => if (old_a = '1') then count = count+1; else
count=count-1; end if; -- state 3
when ("10") => if (old_a = '1') then count = count-1; else
count=count+1; end if; -- state 4
end case;
end if; -- edge detect
end if; -- rst
end process right_way ;
I don't use the STD_LOGIC_UNSIGNED library. It has been so long that
I don't even remember why. I think it has to do with the inability to
use both signed and unsigned in the same code. I suggest that you use
numeric_std instead. Declare your counter as unsigned instead of
SLV.
The only possible problem I see with this code is the startup. I
didn't assign the registers the value of a and b on reset. The reset
shown is a way to specify what the chip will do coming out of the
global reset from configuration. If I want any other resets in the
system, I use synchronous resets.
elsif (rising_edge(clk)) then
if (sync_rst = '1') then
old_a <= a;
...
else
-- state machine logic
end if; -- sync_rst = '1'
end if; -- rising_edge ...
This will give you your starting state so that the decoder does not
have to waste time synchronizing. I thought that it might only take a
couple of clicks to get it sync'd without the reset to a and b, but it
is pathological and always remains unsync'd if started 90 degrees out
*and* it thinks it is rotating the wrong way.
Rick
Article: 132498I was reading about the MathStar FPOA devices and I started thinking about parallels between the architectural advances in CPUs compared to FPGAs. With the increases in speed with process refinements dropping off in the current technologies, CPU makers have taken advantage of the increased density to provide multiple CPUs rather than continually increasing the clock rates. FPGAs on the other hand, continue to increase density by making larger versions of the same chips and trying to push speed as they go. The only exception to this is the way they have incorporated functions on the chip that are not the basic building blocks. I believe it started with memory blocks. Then multipliers were added. Now there are a number of different dedicated functional blocks that are available on the high end FPGA devices. So where is this headed now? My understanding is that the FPOA was a rather coarse grained architecture. I also have the impression that the company is not succeeding because of software issues, not any inherent lacking in the devices or the architecture. In fact, from what I have read, a coarse grained architecture can provide a lot faster processing and higher density than can a fine grained one making the silicon cost a lot lower. With the cost of gates dropping to such low levels, does it really make sense to continue to provide fine grained devices which use so much of the device for routing? I don't remember who first told me, "We sell you the routing and throw in the logic for free!" A coarse grained architecture should require much less of the programmable routing giving you much more of the "free" logic. It seems like the current FPGA devices are heading in the coarse grained direction. They just haven't cut the umbilical cord yet. Most likely because that cord is rooted in the old software. A coarse grained architecture would need a doctor's slap on the behind for the birth of new design tools. So, are coarse grained architectures the way of FPGA... opps FPxA devices in the near future? Will the lowly LUT and FF be pushed into the dark corners of the die in coming years? I think it is not a matter of if, just a matter of when and I think the when is soon!Article: 132499
On 28 Mai, 20:24, <vijayant.rutg...@gmail.com> wrote: > I have a design on FPGA that is ready. However, we need to have some > mapping from fpga design to asic. I know that this will not be > accurate. But accuracy is not our concern right now. We just need > upper bound. Also, we are also looking for some IP Core for ASIC so > that we can rough estimate. Take the nuber of registers and combinatorial cells used for the fpga. Start with the registers, inspect if you have register doubling in synthesis for load balance and ask yourself if you need this register doubling. In ASIC you have often load balancing with buffering. For combinatorical logic you should have a look, what type of cells is in your vendors library. For a lot of technologies the tool will more likely use 3 input cells instead of 4 input cells. This will roughly increase your combinatorical cell count by 10%-30% (it depends on the design). You should take into account, that you need to add something like 10% buffering for global nets and timing correction that comes for free in an fpga. bye Thomas
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