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
Hi, OpenTech is the first world wide package of free open source hardware designs, software and Books for electronics designs. Since 2000 we have sold OpenTech packages to Students, Professors, Engineers, Startup and even large corporations. In OpenTech package you will find many things that you can not imagine they even exists as open source. You will find CPUs , Ethernet, USB and other 300 designs. VHDL, Verilog, Schematic, IC and board layout and many many other software programs more than 300 programs. In short you will find lot of information that helps you in designing your system or testing it. The package is composed of 3DVDs and 1CD that costs only 70 Euros. Use free open source tools and designs in OpenTech package and save more than $500,000 and more than 3 months of download time. OpenTech offers not only these products but also some services to increase the quality of Open source support. We have established the OpenSupport and OpenTech Networks programs for that reason We accept any contributions with tools, designs or books to be distributed with OpenTech packages. For ordering information and the availability please visit http://www.opencores.org/projects.cgi/web/opentech/ http://www.open-technologies.net Best RegardsArticle: 137251
Rob Gaddi wrote: > Bumped for the new year. Come on, anyone got anything on this one? My > FAE is telling me that it can't be done, and that instead I should just > MAXDELAY constrain all of the nets independantly, and guesstimate the > logic and I/O delays to make it all add up nicely, but come on, that > can't be it. Maybe this helps http://www.xilinx.com/support/answers/14644.htm -- Phil HaysArticle: 137252
On 2009-01-05, Andy <jonesandy@comcast.net> wrote: > Are you writing a paper on this or what? Good guess. In fact, quite many of the papers I've been involved with have mentioned "FPGA optimizations" somewhere without truly defining it. Many other papers I have read also say that a design is (or sometimes isn't) optimized for FPGAs. Besides, we talk about optimizing designs for FPGAs here all the time. I know what I'm doing to optimize my designs for FPGAs (as opposed to optimizing a design for ASIC or just plainly optimizing a design for a generic architecture), and I have seen many interesting ideas on this group for example. Even so, I have never really seen a good definition of "FPGA optimized". > Small memories are often easier to use in FPGAs because most FPGA How well I know... :) On the other hand, relatively small memories such as register files (and I'm not thinking about the Cell processors 128x128 bit register file here :)) can be implemented using standard cells without losing that much area. (And unless your volumes are huge you might even gain by not having to worry about the extra verification cost required for verifying a design with many custom blocks in it.) Anyway, thanks for the comments. /AndreasArticle: 137253
On 2009-01-05, jleslie48 <jon@jonathanleslie.com> wrote:
> I'm sure their are different ways to do this, and I would like to
> explore them at a later date, but as I'm still novice at VHDL coding
> I'd like to know what is wrong with this particular code. Its a
> simple debounce process and the synthesize reports an error on line
> 44:
Another thing which I haven't yet seen anyone mention is synchronization
of signals that are not synchronuous with your system clock. Like for
example signals from a button.
This is a very important area which a VLSI designer really needs to
know about. To illustrate, say that you create the following design
in VHDL. x is a signal which is generated externally and which can
change at any time (lets say that it is connected to a button).
-- a, b, and x are all 1 bit wide signals
process(clk) begin
if rising_edge(clk) then
a <= x;
b <= not x;
end if;
end process;
Now, if you simulate this, you will see that a and b mirror each other.
When a is set to 1, b is set to 0 and vice versa (at least if we disregard
all the other values possible in std_logic). And everything always
happens on the rising edge of the clk signal. This should be true
regardless of when x is modified, even if it is modified one delta delay
before or after the rising clock (or even simultaneously with the clock).
The relationship between a and b will still be the same. [1]
However, if you implement this circuit things are not quite as easy.
You will implement two flip-flops and a not-gate [2]. And the delay
x to a will not be the same as x to b. Lets assume that the delay
x to b is longer than the x to a delay. In that case if x is modified
at precisely the wrong time interval (right before the rising clock edge),
it might be that the changing value can be propagated to a before
the clock edge and to b after the clock edge. So in this case it is
no longer guaranteed that a is equal to not b. We basically have a
race condition here.
The way to avoid this is by making sure that the inputs to this
state machine is always synchronuous to the clock edge. One way
to do this is to put a single flip-flop first. Like this:
-- a, b, and x are all 1 bit wide signals
process(clk) begin
if rising_edge(clk) then
x_sync <= x; -- This is the only place where x is used
-- The rest of the design _must_ use x_sync
a <= x_sync;
b <= not x_sync;
end if;
end process;
In this case, even if x is modified close to a clock edge, a and
b will not get out of phase since they both depend on x_sync which
has been synchronized with the clock signal. [3]
Unfortunately the real world is not quite so simple. There is also
something called metastability which it is impossible to avoid in
theory, but in practice it can be avoided by using more than one
synchronization flip-flop. Most usually two flip-flops, but sometimes
three. (See for example http://www.asic-world.com/tidbits/metastablity.html
for more information about this.)
These kind of problems are part of the reason why everyone recommends
that only one system clock should be used in a design if you can get
away with it. Sometimes it is not possible. If you do have a valid reason
for crossing clock domains you really need to understand what is going on.
An introduction can be found at http://www.fpga4fun.com/CrossClockDomain.html
Hope this is of some use to you.
/Andreas
[1] I am quite certain that this will be guaranteed in VHDL even if you
change the signal exactly on the same exact time delay as the clock. I am
unsure whether this is true for Verilog (but I wouldn't bet on it being
true).
[2] Well, it is not certain that you will get that if the synthesis
tool is being clever. But lets ignore that for now.
[3] Assuming the clock frequency is not so high that the routing
and logic delay between x and a,b is too high. But the timing
analysis tool should warn us if there is danger of that.
Article: 137254On Jan 5, 10:56 pm, rickman <gnu...@gmail.com> wrote: > On Jan 5, 9:12 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > On Jan 5, 7:14 pm, rickman <gnu...@gmail.com> wrote: > > > "as I am criticizing... opps, "giving advice", > > > by all means criticize away. I came here for constructive criticism > > and all I've heard > > so far has been great. I'm just stabbing in the dark on my code, so I > > hardly expect I'm picking > > the right/best way of doing things. > > I was just kidding. It is easy to give advice, harder to give good > advice. > > > The reason I used 'variable' was simply because that was what I found > > first in the glossary when > > I was looking for a place to store an integer value and in C we call > > them variables. That's the section > > of the book I read. I didn't know that the more commonly used > > contruct was a SIGNAL. > > That is understandable and there is nothing wrong with variables. You > just have to understand how they work and how they will synthesize. > The best way to learn to code in an HDL is to look at the template > code that the synthesis vendors provide. If you stick with that type > of code, you will have a synthesizable design at least. > > > Now I realize that I've introduced a timing issue where my variable > > 'mycount' will increment at the same > > time that I do the DEBOUNCE_COUNT check, and as a result I may > > (depending on when things within the > > clock pulse occur) not recognize that I've debounced until an > > additional clock pulse, viz, mycount might actually > > reach 6 before it changes SIGNAL_OUT_TEMP (but then it instantly gets > > reset to 0.) > > It's not so much a timing issue as what logic will be generated. The > logic will likely work, it will just be a bit more complex than > needed. > > > >"The synthesis could not "see" your intent and so it threw up its hands > > >and cried "foul"!" > > > - here's my issue. I don't see what my foul was. I agree that > > functionally what I wrote would never work; every > > falling edge of the clock pulse would reset 'mycount' to 0. but I > > don't understand why just because it was stupid > > it wouldn't synthesize. > > It wouldn't synthesize because there is no hardware that will update > both on the rising edge and the falling edge. At least there is none > that I know of. If there is some circuit that will work that way, it > would be so "unique" that the synthesis vendors would not design their > programs to support it. > > > In the case that started this thread, ISE recognized that I did > > something stupid, well, it recognized I did > > something that was impossible to resolve even though my syntax was > > fine. I don't know how it did that. > > The synthesis recognized that it did not know how to construct logic > to implement your design. The simulator would likely have worked just > fine. But the code would have done some weird things compared to > hardware. In fact, you could say that when running the simulator, and > HDL *is* software and when running synthesis, it is *hardware*, or had > better be hardware. > > Your code would run in the simulator (I think) but will update the > mycount variable on the rising edge, as well as the falling edge and > also any time either of the other two signals change. > > > >"I'll point > > > out that your sensitivity list is overly populated. > > > > P1: process (CLK, SIGNAL_IN, SIGNAL_OUT_TEMP)" > > > ahh, so the sensitivity list should only include elements that define > > when my "rising edges" of > > activity should occur, in my case CLK, and in many other cases a RESET > > event. > > SIGNAL_IN is an untimed event that needs to be checked WHEN the CLK > > pulse rises but since by > > itself it cannot be synched up, it is not necessary in the sensitivity > > list. Is that it? > > Yes, exactly. If you look at a template for a register you will see > exactly this. If it is a combinatorial process, all signals on the > right side of any assignments or in condtional part of an if or case > needs to be in the list. > > > And continuing, by forcing values to change based on SIGNAL_IN at a > > rising edge time of CLK, I have made those > > logic element into a D-FF, eg, the event of mycount incrementing > > occurs on the rising edge of the clock and not > > just whenever Signal_in goes high. > > That sounds right. In hardware there is combinatorial logic which is > just made up of gates. There is no clock and any time any input > changes, the output can change. Sequential logic is the term for > registers and latches (slightly different use of the clock) and > constitute memory. A register only changes the output when the clock > has the appropriate edge (some are rising edge and others falling edge > triggered). A latch uses an enable. The input passes through to the > output any time the enable is high. When the enable goes low, the > current output is remembered. Mostly latches should be avoided. They > happen by accident when combinatorial logic is does not specify the > output for all possible input combinations. In that case the > assumption is that the last output should be held which is exactly > what a latch does. This is all well described in pretty much any HDL > design book. > > Rick Thanks again Rick and everyone for a very enlightening discussion. I'm going to continue to see what I can make, (and break) and see if I can apply these ideas. >It wouldn't synthesize because there is no hardware that will update >both on the rising edge and the falling edge. - I'm back to my hardware realization deficiencies. This is definitely my Achilles Heal. I've got a technician who knows 10x more than my EE guys on putting together circuits; throws together cell phone jammers out of spare parts and altoids tin boxes, and never went to college. He just gets it. I'm gonna have to spend more time with him.Article: 137255
<snip> > "as I am criticizing... opps, "giving advice", > > by all means criticize away. =A0I came here for constructive criticism > and all I've heard > so far has been great. =A0I'm just stabbing in the dark on my code, so I > hardly expect I'm picking > the right/best way of doing things. > > The reason I used 'variable' was simply because that was what I found > first in the glossary when > I was looking for a place to store an integer value and in C we call > them variables. =A0That's the section > of the book I read. =A0I didn't know that the more commonly used > contruct was a SIGNAL. <snip> In a somewhat tangential note, one of my new-years resolutions is to finally get over the hump and get to learning Verilog (after several failed attempts at VHDL). I'm also coming from a software background. When I had started playing with VHDL in the past, I picked up several books and read through them, but none of them seemed to hit the "practical" side of developing FPGA code (i.e., their focus was the complete language, and not necessarily related to actually building FPGA-based systems, which I'm assuming the OP is trying to do). Then I stumbled upon the following book: http://www.amazon.com/FPGA-Prototyping-ByVerilog-Examples-Spartan-3/dp/0470= 185325/ref=3Dsr_1_11?ie=3DUTF8&s=3Dbooks&qid=3D1231247475&sr=3D8-11 and its brethren: http://www.amazon.com/FPGA-Prototyping-VHDL-Examples-Spartan-3/dp/047018531= 7/ref=3Dpd_bxgy_b_text_b I have found the Verilog book truly outstanding, doing an excellent job of starting at the beginning (assuming VERY little knowledge other than basic digital logic), and working through the construction of different elements of interest (UARTs, FIFOs, all the way up to the Picoblaze soft-core processor). Very focused on practical development, and building real-world FPGA designs. Yes, this book is specifically targeted at the Spartan 3 FPGA (having a real chip to tackle real examples is always reasonable, IMHO), but there is annotation next to each section that is Xilinx/Spartan specific, so you know what is and isn't generic. Anyway, just figured I'd pass this along. I know everyone learns differently, but this did the trick for me. I have no connection with the author, but am a very pleased customer to have finally gotten over the HDL hump. John O. www.jrobot.netArticle: 137256
On Mon, 5 Jan 2009 16:14:58 -0800 (PST), rickman <gnuarm@gmail.com>
wrote:
>> P1: process (CLK, SIGNAL_IN, SIGNAL_OUT_TEMP)
>> variable mycount : integer := 0;
>> begin
>> if (CLK = '1' and CLK'event ) then --{1
>> if (SIGNAL_OUT_TEMP /= SIGNAL_IN) then --{2
>> mycount := mycount + 1;
>> if (mycount >= DEBOUNCE_COUNT) then --{3
>> SIGNAL_OUT_TEMP <= SIGNAL_IN;
>> mycount := 0;
>> end if; --3}
>> else
>> mycount := 0;
>> end if; --2}
>>
>> end if; --1}
>> SIGNAL_OUT <= SIGNAL_OUT_TEMP;
>> end process P1;
>
>You are using a variable for mycount. I may be showing my ignorance
>of variables, but it is not clear to me exactly what the comparison
>will do since it follows the increment.
>> mycount := mycount + 1;
>> if (mycount >= DEBOUNCE_COUNT) then --{3
>The difference between a variable and a signal has to do with *when*
>you look at the value in other statements. In this case mycount will
>synthesize to a register. It will use an incrementer to do the +1 and
>will use a comparitor to test for >= DEBOUNCE_COUNT.
...
>I am not saying this is a bad design because I am not sure.
Very good points.
Barring synthesis bugs (and XST handles variables pretty well) I would
expect it to do exactly what you want, but be pretty slow.
In one cycle, you will get the increment, the comparison, and the clear
to 0 (possibly a 2:1 mux but more likely the RESET input on a FDRE).
That's a lot of logic in series; it could be as slow as 100MHz.
>If you make mycount a
>signal, then the input to everything within the process will be the
>direct output of the register and the resulting circuit will be very
>clear.
Especially note the comparison is on a registered value, not the
incrementer output, so you get a faster (better pipelined) circuit.
If you don't need 200MHz, either approach works.
(Make sure you understand why the variable version will reset mycount
one cycle earlier; you can modify DEBOUNCE_COUNT to compensate for
that!)
>The rules of signal synthesis is that the value latched in the
>register is the last value assigned during the process. All other
>values are in essence "over written" before the clock edge is done.
>For a variable, each value assigned is in use until the next value
>assigned.
This is the most important point.
To bring out another aspect of it, which emphasises the reason
(and IMO the brilliance) behind the signal assignment rules:
variables are EXACTLY like variables in your familiar "C" environment;
they are local to the process, and between "process" and "end process"
you can pretty much write C (albeit translated into VHDL, with
procedures, functions etc, but with operator overloading, much better
type checking, real booleans, etc). Granted, if you use pointers (access
types) it'll simulate fine but won't be synthesizable, but I suspect the
same is true in these "C to hardware" languages too...
signals are the inter-process communication mechanism. As such, they
require a simple clean update-scheduling mechanism to avoid race
conditions to let you design large parallel processing systems with
minimum pain.
Or hardware.
So a process calculates the new value for a signal, then suspends
itself.
Then, once all processes are suspended, all the signal assignments take
place. This creates "events" on any signals being assigned.
Then, any processes listening for those events are activated.
>P1: process (CLK, SIGNAL_IN, SIGNAL_OUT_TEMP)
>
>You are using a clock, but no reset so the only thing in the
>sensitivity list should be the clock.
...
> The sensitivity list of a process
>is *not* like the parameter list of a subroutine. It tells the tools
>when the process should be run, not what data is going in and out of
>it. Think of this as a trigger list for a concurrent process (because
>that is what it is).
YES!
Limiting sensitivity to "Clk" (and possibly Reset) is not essential;
it's just very good practice.
- Brian
Article: 137257On Jan 4, 2:33=A0am, Petter Gustad <newsmailco...@gustad.com> wrote: > rickman <gnu...@gmail.com> writes: > > I understand how this works in general, but specifically, what > > software is used to initialize the SOF? =A0Is this done in the final > > Usually your hex file will be compiled together with your HDL. > > In your software loop you can then compile your NIOS stuff and keep > the hex or mif files in their same locations and then run: > > quartus_cdb --update_mif projectname > > in order to merge the hex/mif file into the sof file. > > Petter > > -- > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? Hi, thanks alot for the help--> the hex file was the problem -> the memory wasn't initialized by the right hex file... so thanks all... :) GuyArticle: 137258
Hi there, I have a design with part of it as NGC file and the rest as RTL, these two parts need to interact with each other. Is it possible to put both of them into a single FPGA device? Thanks for the reply! XiaolingArticle: 137259
On Mon, 5 Jan 2009 18:12:51 -0800 (PST), jleslie48
<jon@jonathanleslie.com> wrote:
>On Jan 5, 7:14 pm, rickman <gnu...@gmail.com> wrote:
>> On Jan 5, 5:53 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>>"The synthesis could not "see" your intent and so it threw up its hands
>>and cried "foul"!"
>
>- here's my issue. I don't see what my foul was. I agree that
>functionally what I wrote would never work; every
>falling edge of the clock pulse would reset 'mycount' to 0. but I
>don't understand why just because it was stupid
>it wouldn't synthesize. I'm guessing I ended up with two plugs instead
>of a plug and a socket
That's a pretty good analogy actually.
Rickman makes the point that this code will simulate (and do something
odd) but not synthesise. You really have to treat VHDL as, not exactly
as two separate languages, but as having two separate modes of
operation. In C, you would program somewhat differently for Visual
Studio NET edition, and the Microchip PIC C compiler...
In VHDL you (a) have to generate hardware, and (b) have to test it in
simulation. In the latter case, you can use the full language to express
your tests as simply and as comprehensively as you can.
But synthesis is different. The synthesis tool has to translate what you
write into the building blocks available. It actually doesn't try
compiling arbitrary VHDL into raw silicon; it's more like a process of
recognising specific design patterns and translating them into blocks it
already has in hardware.
For example, "Single Process State Machine", "Pure Combinatorial
Process", "Single Clocked Process With Asynch Reset" and so on
(don't look these up in the Gang of Four book; try the Xilinx
"Synthesis and Simulation Design Guide:"
http://toolbox.xilinx.com/docsan/xilinx6/books/docs/sim/sim.pdf
instead!)
As synth tools advance, the number of patterns correctly translated is
increasing, so you'll see discrepancies between older books and recent
practice. Multiplication is now translated well; division is not (the
special case of division by 2^n may be recognised; but there are simpler
alternatives instead!) Floating point is not recognised ... yet, but
it's coming. And so on.
>for example in c:
>x = 0;
>While (x < 10) {
> x++;
> // do something 10 times
> }//while loop 1
This one in a VHDL process could translate successfully; however it
will generate ten identical instances of "do something"; possibly with a
very long combinatorial path through 10 strings of gates...
>>"I'll point
>> out that your sensitivity list is overly populated.
>>
>> P1: process (CLK, SIGNAL_IN, SIGNAL_OUT_TEMP)"
>
>ahh, so the sensitivity list should only include elements that define
>when my "rising edges" of
>activity should occur, in my case CLK, and in many other cases a RESET
>event.
Yes; though not every process needs to be clocked.
GATE: process (a,b)
begin
d <= a and b and c;
end process GATE;
is a perfectly legal description of a 3-input AND gate.
It won't simulate quite as desired of course, and it might synthesise,
but I would hope for a warning about the incomplete sensitivity list...
Combinatorial processes are legitimate, and synthesisable, but
error-prone (as above!) - mixing clocked and combinatorial in the same
process is definitely not recommended.
One pattern you will often see in older books, that is definitely NOT
recommended now, is "Two (or three) process state machine". It has one
clocked process which simply registers the current state, and a separate
(purely combinatorial) process which computes the next state from
current state and input signals. (And a third process for outputs)
In the real world, with deadlines looming, someone inevitably updates
the combinatorial process and forgets to update the sensitivity list.
Oops...
- Brian
Article: 137260On 2009-01-06, Andreas Ehliar <ehliar-nospam@isy.liu.se> wrote: > These kind of problems are part of the reason why everyone recommends > that only one system clock should be used in a design if you can get > away with it. Sometimes it is not possible. If you do have a valid reason > for crossing clock domains you really need to understand what is going on. > An introduction can be found at http://www.fpga4fun.com/CrossClockDomain.html Before someone else corrects me, I should also point out that the synchronization technique I mentioned in my previous posting will only work correctly for 1-bit wide signals. If you have vectors as input or want to send multiple bits over a clock domain you really need to read an article like the one I mentioned above to understand what is going on. /AndreasArticle: 137261
On Tue, 06 Jan 2009 15:43:47 +0000, Brian Drummond wrote: >In VHDL you (a) have to generate hardware, and (b) have to test it in >simulation. In the latter case, you can use the full language to express >your tests as simply and as comprehensively as you can. > >But synthesis is different. [etc, etc] A very nice description. Thanks. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 137262
On Jan 6, 9:30=A0am, bonnerfme <xiaoling...@fme.fujitsu.com> wrote: > Hi there, > > I have a design with part of it as NGC file and the rest as RTL, these > two parts need to interact with each other. Is it possible to put both > of them into a single FPGA device? > Thanks for the reply! > > Xiaoling Yes it is, assuming that the NGC is intended to be instantiated by higher level HDL. The NGC netlist is considered a black box that can be instantiated by HDL. Read the XST section on black boxes for more information on how to use them from XST. If you are using EDK, also read the psf_rm manual section about black box definition files. Regards, John McCaskill www.FasterTechnology.comArticle: 137263
Hello all, I've just finish my design. It is a simple hardware only, no NIOS inside. Now I would like to make it automatically "uploaded" to the fpga on board's power up. I am using Terasic DE3. I read that I need to convert the sof file to jic and the program the EPCS flash... Is it true? I've tried to do so but... it doesn't work I get an error - Info: Configuration succeeded -- 1 device(s) configured Error: Can't recognize silicon ID for device 1 Error: Operation failed Info: Ended Programmer operation at Tue Jan 06 16:30:31 2009 So I am a bit lost here..... Any help is more then welcome... thanks, GuyArticle: 137264
On Dec 30 2008, 6:50=A0am, St=E9phane Goujet <stephane.n...@wana.invalid> wrote: [snip] > and new regular prices are 20 to 40 USD higher (which is a huge increase= in > percentage) Hi St=E9phane, Which boards in particular? I haven't seen the price change on the Basys or Nexys 2 boards, which are still $59 and $99 respectively. It don't remember the previous pricing but it does seem that the pricing on Digilent's older products has increased. Maybe they are trying to enourage customers onto the Basys and Nexys platforms. -- Steve Knapp Prevailing Technology, Inc. www.prevailing-technology.comArticle: 137265
thanks again for the insight everybody. a few thoughts to continue,
1) changing line 44 getting rid of the unnecessary sensitivities:
P1: process (CLK)
resulted in a warning:
WARNING:Xst:819 - "//dhpc-1/shared/jon/MyVhdl/VhdlModule1.vhd" line
44: One or more signals are missing in the process sensitivity list.
To enable synthesis of FPGA/CPLD hardware, XST will assume that all
necessary signals are present in the sensitivity list. Please note
that the result of the synthe
sis may differ from the initial design specification. The missing
signals are:
Note that I didn't cut off the message, suspiciously there were no
signals listing after the "The missing signals are:" line.
2) the building block issues:
(a) "In VHDL you (a) have to generate hardware, and (b) have to test
it in
simulation. In the latter case, you can use the full language to
express
your tests as simply and as comprehensively as you can.
But synthesis is different. The synthesis tool has to translate what
you
write into the building blocks available. It actually doesn't try
compiling arbitrary VHDL into raw silicon; it's more like a process of
recognising specific design patterns and translating them into blocks
it
already has in hardware. "
(b)"Rickman makes the point that this code will simulate (and do
something
odd) but not synthesise. You really have to treat VHDL as, not exactly
as two separate languages, but as having two separate modes of
operation."
(c)"Now, if you simulate this, you will see that a and b mirror each
other.
When a is set to 1, b is set to 0 and vice versa (at least if we
disregard
all the other values possible in std_logic). And everything always
happens on the rising edge of the clk signal. This should be true
regardless of when x is modified, even if it is modified one delta
delay
before or after the rising clock (or even simultaneously with the
clock).
The relationship between a and b will still be the same. [1]
However, if you implement this circuit things are not quite as easy.
You will implement two flip-flops and a not-gate [2]. And the delay
x to a will not be the same as x to b. Lets assume that the delay
x to b is longer than the x to a delay. In that case if x is modified
at precisely the wrong time interval (right before the rising clock
edge),
it might be that the changing value can be propagated to a before
the clock edge and to b after the clock edge. So in this case it is
no longer guaranteed that a is equal to not b. We basically have a
race condition here. "
From what was quoted in (a,b,c) above, it seems to me that simulation
doesn't
really do a very good job of simulating what is actually going to
happen then.
(c) actually this one sort of makes sense, as there is no control on
when x can change,
Article: 137266On Tue, 6 Jan 2009 13:57:16 -0800 (PST), jleslie48 wrote: [...] >From what was quoted in (a,b,c) above, it seems to me > that simulation doesn't really do a very good job of > simulating what is actually going to happen then. I think this misses the point. VHDL and Verilog are designed and defined as simulation languages, and simulation does an excellent job of showing you what the code says should happen. The culprit here is synthesis. Synthesis is honour-bound to do one of two things: either build logic that matches (at the clock cycle level) the simulation behaviour, or throw an error. Unfortunately, for various historical (hysterical?) reasons, synthesis sometimes chooses to ignore certain language constructs that it can't faithfully reproduce in logic, giving only a warning message at best. This is the all-too-familiar problem of synthesis/simulation mismatch. The usual culprits are: - wrong sensitivity list (synthesis assumes a complete sensitivity list on non-clocked processes) - time delays in your simulation code (synthesis simply ignores all time delays) - pragmas or directives in the code that are meaningful to synthesis but, being embedded in comments or user-defined attributes, are ignored by simulation - state machine encoding attributes, and the dreaded Verilog full_case/parallel_case and a few other, less common things. In fairness, engineers who take the trouble to read and correctly interpret synthesis warnings will rarely get bitten by such mismatches. But it's a little tiresome that you can flog your way through extensive simulation and only at synthesis time finally discover that you have written some code that doesn't map sensibly to hardware. That's why many engineers (me included) will typically do trial synthesis runs very early in the life of a project, long before functional behaviour is fully debugged. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 137267
">for example in c:
>x = 0;
>While (x < 10) {
> x++;
> // do something 10 times
> }//while loop 1
>This one in a VHDL process could translate successfully; however it
>will generate ten identical instances of "do something"; possibly with a
>very long combinatorial path through 10 strings of gates... "
this doesn't make sense to me. ~will generate ten identical instances
of "do something"~
it can't be that raw. what if that loop was (x< 10000000)? it can't
simply make yyy copies
of the same line by brute force. YOu'd fill your memory in 2 seconds.
and what if the initial
value of x was not a "synthesize" fixed value? what if :
-- read x from a UART
-- for x number of times
-- do something.
then there would be no way to make the right number of instances at
synth time.
Article: 137268
On Tue, 6 Jan 2009 13:57:16 -0800 (PST), jleslie48
<jon@jonathanleslie.com> wrote:
>
>thanks again for the insight everybody. a few thoughts to continue,
>
>1) changing line 44 getting rid of the unnecessary sensitivities:
>
> P1: process (CLK)
>
>
>resulted in a warning:
>WARNING:Xst:819 - "//dhpc-1/shared/jon/MyVhdl/VhdlModule1.vhd" line
>44: One or more signals are missing in the process sensitivity list.
Assuming the modified process still looks like...
> > P1: process (CLK, SIGNAL_IN, SIGNAL_OUT_TEMP)
> > variable mycount : integer := 0;
> > begin
> > if (CLK = '1' and CLK'event ) then --{1
...
> > end if; --1}
> > SIGNAL_OUT <= SIGNAL_OUT_TEMP;
> > end process P1;
... notice the assignment outside the "if CLK..." statement?
You have 2 options:
(a) restore SIGNAL_OUT_TEMP to the sensitivity list;
(b) move the assignment where it belongs, outside the process.
Then it is a separate parallel process sensitive only to SIGNAL_OUT_TEMP
(but a trivial one).
- Brian
Article: 137269
On Tue, 6 Jan 2009 15:24:31 -0800 (PST), jleslie48
<jon@jonathanleslie.com> wrote:
>">for example in c:
>>x = 0;
>>While (x < 10) {
>> x++;
>> // do something 10 times
>> }//while loop 1
>
>>This one in a VHDL process could translate successfully; however it
>>will generate ten identical instances of "do something"; possibly with a
>>very long combinatorial path through 10 strings of gates... "
>this doesn't make sense to me. ~will generate ten identical instances
>of "do something"~
>it can't be that raw. what if that loop was (x< 10000000)? it can't
>simply make yyy copies
>of the same line by brute force. YOu'd fill your memory in 2 seconds.
Ohhhh yes it can! you'd fill your FPGA, sure.
But I said it would work; not that it was always a good idea!
Now if you wanted to generate a single instance of "do_something" which
took 10 clock cycles, you would use a different pattern; possibly with a
"wait for rising_edge(clk)" inside the while loop. Or in the process
style you have seen so far, maintain a separate counter to know when
you're done.
One thing we don't have, yet, is any semi-automatic way to combine both;
unroll your loop to 1000 parallel instances, and count 10000 cycles.
That level of detail you have to handle yourself. Not just the
compromise; how fast do you need it, and how big is your FPGA? but the
execution details.
>and what if the initial
>value of x was not a "synthesize" fixed value? what if :
>
>-- read x from a UART
>
>-- for x number of times
> -- do something.
>
>then there would be no way to make the right number of instances at
>synth time.
This is a good question. The short answer is that x has to be locally
static, since you can't (yet!) grow more hardware at runtime.
So transform the problem into something achievable.
The usual pattern is to agree an upper bound on x, and implement that
upper bound in hardware, executing do_something conditional on the
actual value.
constant x_max:integer := 15;
for i in 1 to x_max loop
if i < x then
... No, it's better, safer and tidier to use the type system properly:
subtype x_type is integer range 0 to 15;
signal x : x_type;
-- this is inside a process of course!
for i in x_type loop
if i < x then
do_something;
end if;
end loop;
If do_something is synthesisable, so is this.
- Brian
Article: 137270This board probably has an Altera serial configuration device on it. And yes, you can program the serial configuration device through JTAG via the FPGA, which requires a .jic file. You first need to instantiate the Serial Flash Loader (SFL) into your design. Go to the MegaWizard and look for it under the section titled "JTAG accessible Extensions". Guy_FPGA wrote: > Hello all, > > I've just finish my design. It is a simple hardware only, no NIOS > inside. Now I would like to make it automatically "uploaded" to the > fpga on board's power up. I am using Terasic DE3. I read that I need > to convert the sof file to jic and the program the EPCS flash... Is it > true? > > I've tried to do so but... it doesn't work I get an error - > > Info: Configuration succeeded -- 1 device(s) configured > Error: Can't recognize silicon ID for device 1 > Error: Operation failed > Info: Ended Programmer operation at Tue Jan 06 16:30:31 2009 > > So I am a bit lost here..... > > Any help is more then welcome... > > thanks, > > GuyArticle: 137271
On Jan 6, 3:34=A0pm, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote: > On 2009-01-05, Andy <jonesa...@comcast.net> wrote: > > > Are you writing a paper on this or what? > > Good guess. In fact, quite many of the papers I've been involved with > have mentioned "FPGA optimizations" somewhere without truly defining > it. Many other papers I have read also say that a design is (or sometimes > isn't) optimized for FPGAs. Besides, we talk about optimizing designs > for FPGAs here all the time. > > I know what I'm doing to optimize my designs for FPGAs (as opposed to > optimizing a design for ASIC or just plainly optimizing a design > for a generic architecture), and I have seen many interesting ideas > on this group for example. Even so, I have never really seen a good > definition of "FPGA optimized". > > > Small memories are often easier to use in FPGAs because most FPGA > > How well I know... :) On the other hand, relatively small memories such > as register files (and I'm not thinking about the Cell processors 128x128 > bit register file here :)) can be implemented using standard cells withou= t > losing that much area. (And unless your volumes are huge you might even > gain by not having to worry about the extra verification cost required fo= r > verifying a design with many custom blocks in it.) > > Anyway, thanks for the comments. > > /Andreas Hey I have one more point 7. Writing the Constraint File in a very logical and intelligent way. I believe Constraints play a major role in the design Optimizations and finally improves the Quality of result.Article: 137272
Hello, During my project I find myself obliged to use the FTDI2232 device to communicate with my Xilinx platform. Indeed, I would like to program my FPGA (Virtex) using "openocd" tool. I have tried to release the config files (interface,board and target). The problem is that is not simple as I thaught and there no exemple about this. Thank you.Article: 137273
Hi Rob, thanks for your response... I've managed to solve the problem without SFL. If I convert my design to jic file and then try to program the device with the programmer pointing to my jic file then altera prorams the fpga with its own sfl sof (not mine that doesnt contain a SLF). Later on power up the fpga loads the data from the flash automatically. thanks... GuyArticle: 137274
On 2009-01-07, Svenn Are Bjerkem <svenn.bjerkem@googlemail.com> wrote: > Hi, > found a thread on revision control from 2001 here, but obviously some > of the newer tools weren't available back then. We currently use > Subversion for anything and I find it kind of awkward to use for RTL. > Obvious alternatives are CVS and git. Have people found new favourite > tools since then? I'm using SVN as well. I think the only real problem is when used in conjunction with ISE (because ISE's config files are mostly binary instead of text). To work around this (and to gain other advantages) I'm using a Makefile based build system for larger projects and a simple synthesis script for smaller projects (where it doesn't matter if everything has to be resynthesized every time). Anyway, I'm not involved in projects which has lots of participants, so I can't vouch for SVN:s greatness for HDL code in large projects, but it has worked very well for us when developing HDL code for various courses and research projects. (Around 3-5 developers who fiddle with the code occasionally.) /Andreas
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