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
> If I knew enough to ask the right question I could probably find > the answer myself. Or ask here, or ... That's true Hal, sometimes the problem is we have gaps in our knowledge that we don't realise... > The main reason I go to a class is to learn something about a topic > when I don't know enough about it to ask the right questions. ...or we don't even know where to start. In which case asking the instructor questions ahead of time won't be too helpful, except maybe a good instructor will be able to guage where a student needs help by the types of questions they ask.Article: 61601
Macie, Xilinx offers an AWGN core that includes the VHDL source code. See the following link for further details: http://www.xilinx.com/ipcenter/catalog/search/logicore/xilinx_awgn.htm Regards, Ed Hemphill MACEI'S wrote: > Hi guys, > > Does anybody have any idea or any link or code for Additive White > Gaussian Noise in VHDL ? Or any body have written it or not ? > > Also how to generate Random Number's in VHDL? > > Thanks > > Rgds > > MacieArticle: 61602
What's so special about FPGAs? Is there any 2-day course that makes: a law student into a crack lawyer a fresh doctor into an expert surgeon, a newly-married into a gourmet cook (note, I am p.c. and gender-neutral!) a high-school student into a fluent French speaker ( if not French-born) an engineer into a good presenter (or writer) a hardware-guy into a VHDL expert (I wish there was...) Of course there is not. Learning takes time, effort, patience, and disappointing detours. Why does anybody expect to get a chance to soak up relevant wisdom eight hours a day? What is a revelation to one student is old hat to another and irrelevant to a third. Peter AlfkeArticle: 61603
> While you may know enough to ask the right question, getting from there to > an answer might not be all that simple. You can bounce around the online > documentation from manual to manual and not get very far. Yeah the answer you want can be buried under tons of other answers in the documentation, and worse yet it might be broken up into pieces and scattered about. Documentation these days include search functions, but nothing beats an experienced human who can understand what a person wants even if they can't articulate it well.Article: 61604
"Peter Alfke" <peter@xilinx.com> wrote in message news:3F830E67.CF313B57@xilinx.com... > Why does anybody expect to get a chance to soak up relevant wisdom eight > hours a day? What is a revelation to one student is old hat to another > and irrelevant to a third. As trainers, we have to deal with this fact every working day. As you hinted, Peter, there is as much specialist expertise in being a good trainer as there is in being a good engineer. We try very hard indeed to give each course delegate a happy and valuable experience; that means carefully tweaking what we say and how we act, in response to the needs of individuals. That's why real warm pinkware trainers will go on being valuable for a while yet, despite distance-learning and web-accessed courses. It also means that we must continually take active steps to keep up-to-date and technically aware ourselves. Our clients (or, at least, their employers) are paying us money for courses, and expect results. If they're reasonable people, they don't expect to get *everything* they need to know from a training course. But they reasonably expect to get enough new expertise, and enough help in steering around the topic's worst pitfalls, that when they return to work they will be able to save at least as much as the course has cost them. Here's my spin on it - your mileage may vary, but the conclusions are inescapable: cost of a course: around $300-$600 per day travel and out-of-pocket expenses for the trainee: around $200/day total cost to the employer of losing an engineer from his/her desk: around $300-$500/day (in the US or Europe, anyways) sheesh... that's big $$$ for a 3 or 5 day course. But wait a moment... if the course can give the engineer new expertise that prevents an error, and that error would have cost a few days to find, and a few days of time-to-market, and a few days of several other engineers' wasted time hanging around... perhaps the course isn't such bad value after all. And that's even before you start to count the downstream benefits of improved techniques finding their way into your normal working practices, and the time that other engineers would have wasted helping you to get up to speed. The challenge for trainers is to understand what trainees need, and continually to improve what we deliver to meet that need better. I'm sad that someone as expert as Mike Treseler (a couple of posts back, in this sub-thread) has had such consistently negative experiences. All I can say is that I hope he fed back his criticisms to the trainers, and that I hope my outfit's batting average is rather better. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 61605
I prefer the default H_sets, as that allows me to build up a larger macro from my
library of smaller pieces so that individual piece just need an RLOC when they
get instantiated to put them in their place. Leave off the RLOC, and it becomes
a placed macro that can be moved around relative to other placed macros. The
caution is that you must not let the tools flatten the design.
Goran Bilski wrote:
> Hi,
>
> I will try to explain it from my view.
> There exists an explanation on the RLOC in the ISE documentation.
> Look under RLOC in the constraint guide and you will see how it works.
>
> U_SET (User_SET) names have to be unique in the design and all RLOC
> attributes where ever they are specified in the design hierarchical
> works within the same U_SET name domain.
> ex. If you have a top level where you add a primitive to a U_SET (like
> X1Y0) and then in a submodule add another primitive to the same U_SET
> name with the values of (X1Y1) then they will be using the same
> co-ordinate system.
>
> But with HU_SET (Hierarchical User Set) or H_SET the submodule starts
> with a new co-ordinate system for each hierarchical level and so for
> each submodule you have to specify the relation between the level
> co-ordinate system and the submodule system.
> This makes it hard to down in a hierarchical design place a primitive
> close to another primitive in another branch of the hierarchical since
> you have to know all the relations of the co-ordinate systems between
> the two primitives.
> One difference between H_SET and HU_SET is with HU_SET you can give it a
> name instead of relying of the design hierarchical. The name has to be
> as for the U_SET unique within the design.
> Another difference is that with H_SET everything within a level with a
> RLOC is automatically in the set but with HU_SET, you have to manual
> assign the primitives to the SET (ala U_SET).
>
> Another way of looking at it is that U_SET flattens the hierarchical and
> all RLOCs within the same name uses the same co-ordinate system.
> HU_SET/H_SET preserves the hierarchical and each level has it's own
> co-ordinate system.
>
> Personally I only uses U_SET since it will give me one co-ordinate
> system independent where in the design I place something. The U_SET have
> the catch that you can only have one unique name in your design and if
> you want to have multiple instances, you need to name them differently.
> I have added a generic of the type string in my VHDL RPMs which the
> module uses as the U_SET name.
> For each new instance of the module, I give it a new name.
>
> Göran
>
> John_H wrote:
>
> >When I specify RLOCs in my UCF file manually, I have to associate a U_SET
> >for each group to keep the RLOCs associated with the unique U_SET name. Are
> >you using unique U_SET names for each instance of your module? Or are you
> >using "hierarchical" HU_SETs? I haven't messed with those myself.
> >
> >Perhaps someone who regularly does RLOCs in their code can help explain how
> >to make the groups unique and seperable since my experience hasn't touched
> >on hierarchical RLOCs.
> >
> >
> >"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
> >news:TJugb.12278$hT5.11925@newssvr25.news.prodigy.com...
> >
> >
> >>So...I have this little module that creates an RLOC'd SRL-based delay pipe
> >>that will feed one side of an adder in an FIR filter. Floorplanner
> >>
> >>
> >confirms
> >
> >
> >>that the RLOCs are working as promised.
> >>
> >>However, if I instantiate more than one of these modules, only the first
> >>
> >>
> >one
> >
> >
> >>is placed per the defined RLOCs and the rest are placed with SRL's and
> >>
> >>
> >FF's
> >
> >
> >>outside of the required relative locations. I've looked through every
> >>report and I cannot find any warnings that would indicate that there's a
> >>problem of any kind.
> >>
> >>I also wrote and compiled a simplified version of the above to see if
> >>anything changed. The RLOC'd module consists of eight SRL's feeding eight
> >>FF's, RLOC'd to form a column. I instantiated two of these to then feed
> >>
> >>
> >an
> >
> >
> >>8-bit adder that clocks out to 8 FF's. The layout I got confirms the
> >>problem: The first module follows the RLOCs and the second does not.
> >>
> >>What's interesting is that section 7 of the MAP report lists two RPM's by
> >>their set name (for the last example) but section 13's "Number of RPM
> >>Macros" count is 1.
> >>
> >>Not sure where to go from here...
> >>
> >>
> >>
> >>--
> >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>Martin Euredjian
> >>
> >>To send private email:
> >>0_0_0_0_@pacbell.net
> >>where
> >>"0_0_0_0_" = "martineu"
> >>
> >>
> >>
> >>
> >
> >
> >
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 61606
I'm guessing this is video. If that is the case, you've probably got an
incoming pixel clock and data that is timed to that clock that you want to
get on to the internal 108 MHz clock. In an ideal world, you could use
the DLLs to multiply the pixel clock by 4 to get your internal clock.
Unfortunately, the pixel clock from most of the popular decoders has far
too much jitter to keep the DLLs happy, so you are more or less forced to
use an unrelated local clock.
So how to do it? Clock your incoming pixel data into the FPGA on the 27
Mhz pixel clock, and also toggle an additional flag bit. A change on the
flag bit corresponds to new data getting clocked in. Synchronize that
flag bit output to the 108 Mhz clock using a single flip-flop, then detect
the change in the synchronized flag with a synchronous edge detect state
machine. I use a state machine designed so that only one bit is
sensitive to the synchronized toggle signal and which generates a 1 clock
wide pulse in response to a level change on the toggle input. For low
clock rates, you can do without the synchronizing flip flop preceding the
state machine because the toggle input only effects one state bit. The
state machine I use is:
case state is
when "00" =>
if sync='1' then
next_state<="01";
else
next_state<="00";
end if;
when "01" =>
next_state<="10";
when "10" =>
if sync='0' then
next_state<="11";
else
next_state<="10";
end if;
when "11" =>
next_state<="00";
when others=>
null;
end case;
The state(0) bit out of that state machine is a one clock wide pulse.
That is used to copy data from the register holding the pixel data to a
second register in the 108 MHz clock domain. This method takes up about 3
clock cycles of time, leaving little margin for the 27 MHz to 108 MHz
transfer, so a modification is in order. In order to handle the
relatively frequent 27 mHz inputs, instead of presenting each pixel, the
27 MHz logic consists of a 2 deep shift register that captures 2 pixels
and holds them both for 2 cycles of the 27 MHz clock. The flag flip-flop
is replaced by a 2 bit counter whose MSB toggles at the same time the 2
pixel register outputs are updated. Then the synchronized write pulse is
used to transfer 2 pixels at a time (in parallel) to the register in the
108 MHz clock domain. By construction, the data at the clock domain
boundaries is guaranteed to be stable when the state machines write pulse
(state bit 0) pulses.
Now, somehow you'll have to provide some elasticity since the 108 MHz
clock is not exactly 4x the 27 MHz clock. This can be handled with a
FIFO, or by dropping or repeating samples. In the case of video, it is
often best handled by writing to a frame buffer, and then fetching from
the frame buffer later so you don't have to deal with missing or extra
pixels later in your process.
Guy Eschemann wrote:
> Hi,
> I need to synchronize an incoming 27MHz signal (50% duty cycle) with
> an internal clock running at 108Mhz (which is 27*4, but the signals do
> not have a known phase relationship). The target technology is Spartan
> II-E.
>
> Is a simple 2-stage DFF synchronizer a safe way to handle this ? (I
> remember a Xilinx article stating that metastability can be ignored
> for clock rates < 200MHz).
>
> Many thanks,
> Guy.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 61607
If he is using the Phillips decoder, then no. The decoder has a PLL in it
that adjusts itself to match the sync data in the incoming stream. The
decoder's PLL output also has way too much jitter for the DLL in the FPGA.
Marc Randolph wrote:
> At the risk of proposing something you've already thought of, is there
> really no way to use the 108 MHz clock in the FPGA as the source of the
> 27 MHz clock that video data source uses, so that there is a known phase
> relationship between the two? If you can swing that, they'll be in the
> same domain and all you have to worry about is a non-varying setup time.
>
> Marc
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 61608
Nope, Jitter out of the video decoders is about 10x what is allowed by the
DLL/DCM. I posted earlier a solution that works fine for this, and is used in
a number of my customer's products.
Simon Peacock wrote:
> If you pick the right xilinx you could multiply the 27MHz up to 108MHz
> internally. Just use the internal PLL
>
> Simon
>
> "Guy Eschemann" <geschemann@yahoo.fr> wrote in message
> news:b9f16a5b.0310062304.4b75202a@posting.google.com...
> > > But you said that the clock was not truly asynchronous, but was 4 times
> > > the data rate, with an unknown ( but stable?) phase relationship.
> > >
> >
> > Maybe my description was a bit confusing, sorry for this. The clocks
> > really are asychronous. There is no stable phase relationship between
> > them, since the 27MHz clock is the ouput of a PLL locked on the H-Sync
> > of a video signal, and the 108MHz system clock is derived from a 27MHz
> > crystal oscillator.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 61609
A caveat applies to crossing between the 1x and 2x domains. Although there is a specification for skew
between the 1x and 2x outputs of a DLL/DCM, that spec is predicated on no jitter in the input clock and
balanced loads on the 1x and 2x domains. In practice you wont get that, and you can wind up with a sizable
skew between the 1x and 2x clocks. We saw an instance a while back with a customer where there was nearly 1
ns clock skew between the 1x and 2x clock that caused all sorts of problems with transferring data across the
domains. The skew was mostly due to clock jitter, and most of that clock jitter was due to outputs switching
on the same bank as the clock input, not from outside the FPGA.
Since then, I have strongly advocated a safe transfer between 1x and 2x domains that makes sure the 2x clock
is clock enabled so as to sample away from the 1x edges going from 1x to 2x, and going the other way clock
enabled so that the edges on the 2x data occur away from the edges of the 1x clock. To do that, copy the 90
degree 1x clock into the 2x domain and use that to generate a 1x clock enable in the 2x domain. The 90
degree reference makes sure the phase is correct and provides a way to sample the 1x clock without getting on
the edge. You could use the 90 degree clocks directly, but for high speed designs the place and route can be
very tricky. This little trick guarantees safe transfers even with a substantial clock skew.
John_H wrote:
> "Morten Leikvoll" <m-leik@online.nospam> wrote in message news:<IP8gb.28381$os2.396615@news2.e.nsc.no>...
> > My collegue and I discussed how our placer (xilinx's) handled going from 1x
> > clocks to 2x clocks and back. (These have of course common rising edge)
> >
> > For this example I use a 100Mhz clock and a 200Mhz clock:
> >
> > There are 3 ways of doing this:
> >
> > 1 (based on the timing of the previous ff's output ) Signals coming from 1x
> > to 2x will be routed with max 10ns delay. This means that you can not tell
> > wether the signal will appear at the 2x at the 5ns or 10ns rising 2x clock.
> >
> > 2 (based on the input timing) Signals coming from 2x to 1x will be routed
> > with max 10ns delay. This means that the output can sometimes skip the first
> > 1x edge.
> >
> > 3 (based on the lowest delay of input and previous output) This works, but
> > my collegue claims this tool doesn't do it this way. Can anyone confirm this
> > is the case?
> >
> > How DOES the placer tool handle this?
>
> If you check your source and destination clocks for the timing in your
> timing analyzer, you'll see that the timing is based on 5 ns, not 10
> ns. Unless you tell it otherwise with your timing constraints, the
> tools assume that something generated in one domain will be used in
> the other domain on the earliest rising edge. The logic will require
> the 5 ns times unless you have explicit enables in the 200MHz domain
> and specific logic to keep the 200 MHz outputs steady for 2 clocks
> going back to the 100 MHz domain. Everything ends up being timed to
> the faster clock. Can you explain how a 10 ns delay either direction
> would work properly given the data changes 5 ns before the clock edge
> (at least for *a* rising edge for the 100 MHz to 200 MHz transition).
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 61610
Use the DXN and DXP balls of the device along with a MAX6687 from
Maxim semi to make a thermometer. The FPGA will use remarkably little
power in this mode, as long as you don't connect any of the other 955
pins.
HTH, Symsx.
(p.s. Or you can also use the same pins in the feedback path of an
op-amp to use the FPGA in its secret, unpublished 'logarithmic' mode.)
banktrade2002@yahoo.com (Emile) wrote in message news:<952209fb.0310070512.731ec498@posting.google.com>...
> Can someone suggest a project/application that would call for an
> XC2V6000-4BF957C? Thanks.
>
> -Emile
Article: 61611"Ray Andraka" wrote: > Make sure you are preserving the hierarchy, it sounds like either the hierarchy > is being flattened or that you have overlapping RLOCs within the same Uset. I > generally don't use explicit USETs in my code, as I've had trouble on and off > with the tools properly passing them through. Look in your edif netlist to see > what it is doing. You should see one instance of your macro, and then multiple > instantiations of it in the main part of the code. Lot's of interesting replies. I'll lump my responses here. Yes, I tried all combinations of U_SET and HU_SET with unique names for each instantiated module. An example: (* HU_SET = "DLY00" *) SRL_DLY #(.WIDTH(10), .DELAY( 2)) DLY00(.CLK(clk), .IN(a), .Q_OUT(a_dly[0]), .Q15_OUT()); (* HU_SET = "DLY01" *) SRL_DLY #(.WIDTH(10), .DELAY( 4)) DLY01(.CLK(clk), .IN(a), .Q_OUT(a_dly[1]), .Q15_OUT()); I also tried assigning U/HU_SET inside the "SRL_DLY" module using "generate" to actually attach every generated entity to the corresponding set. This didn't work. Setting "Keep Hierarchy" to "Yes" did not fix the problem. I tried this with unique U_SET and HU_SET attributes as well as without any sets defined. Nothing seemed to make a difference. At the risk of sounding stupid. I can't find an EDIF (old ".edn")file anywhere and NGD2EDIF doesn't seem to be supported any more (running 6.1i). Where do I look? I used NGD2VER to create a simulation model. It clearly shows one instance of the macro and two instantiations. However, all placement info is gone, as this is a simulation model. Some have mentioned the specification of RLOCs in the UCF file. All of my RLOCs are defined in the HDL file for the module in question. That way the module is easily reusable in other projects and you can build more complex circuits with placement already defined at various levels of the hierarchy. I'm just getting into this (as most can tell). I don't like the UCF approach. It's not portable at all. If you wanted to move modules to another design it would be a very ugly cut and paste session. Someone mentioned that the Constraints Guide has an explanation of RLOCs. Just know that before I decide to post anything on a newsgroup I try to exhaust all possible sources to the point of frustration. I spent all day (defined as >12 hours) yesterday reading just about anything you could find about RPMs, RLOCs, H/U/HU_SETS and related subjects in the online manuals, Google, techXclusives, app notes, answer database, etc. I posted my message at 1:30AM, when I finally threw my hands up. In other words, the newsgroup is not a replacement for doing the necesary work, it's a resource that I think most should (and do) use after they've exhausted all other possibilities. That simply out of respect to those who've put in years of work to be able to solve your problem in five minutes. The RLOC section of the Constraints Guide does a good job of treating RLOCs in isolation, but if fails to connect the greater subject of RPM's and, perhaps, their use in floorplanning. The heading, for example, does not even mention the finer-grain control you can have by using the BEL attribute (thanks Ray!). It also deals with RLOCs in isolation of HDL (other than offering HDL syntax), hence my current endevour to re-invent of the wheel. Another area not mentioned (appropriately, as it is a separate subject) is that of the various considerations or consequences of choosing a particular BEL with respect to how it affects routing (switch box) and general connectivity to other parts of your design. In other words, a nice column of logic might not be the best way to lay something out if you need to route in/out of block RAM, etc. I'll post the code in a separate message to keep this one short. Thanks, -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 61612
This is the module with the RLOCs. I'm just hacking away here, so it's not perfect code. The long list of RLOC/BEL attributes is there because I haven't been able to figure out how to integrate that into the "generate" portion of the code. I don't see a way to construct the attribute string --even with the V2001 (*...*) attribute format. Yet another case for VHDL :-( Code below. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" // Generates an SRL-based shift register of the desired word width and delay (in clocks) // A minimum delay of 2 clocks is required, as the output is registered. // "Q15_OUT" is the cascading SRL output, used to get 16 clocks of delay, regardless // of the DELAY setting. // module SRL_DLY #(parameter WIDTH = 8, DELAY = 2) ( input wire CLK, input wire [WIDTH - 1:0] IN, output wire [WIDTH - 1:0] Q_OUT, output wire [WIDTH - 1:0] Q15_OUT ); localparam D = DELAY - 2; wire [WIDTH - 1:0] qw; genvar i; generate for(i=0; i < WIDTH; i=i+1) begin:BIT SRLC16 SRL(.Q(qw[i]), .Q15(Q15_OUT[i]), .A3(D[3]), .A2(D[2]), .A1(D[1]), .A0(D[0]), .CLK(CLK), .D(IN[i])); FD DFF (.Q (Q_OUT[i]), .C (CLK), .D (qw[i])); end endgenerate // RLOC the SRLC16 primitives // //synthesis attribute RLOC of BIT[0].SRL is X0Y0 //synthesis attribute BEL of BIT[0].SRL is F //synthesis attribute RLOC of BIT[1].SRL is X0Y0 //synthesis attribute BEL of BIT[1].SRL is G //synthesis attribute RLOC of BIT[2].SRL is X0Y1 //synthesis attribute BEL of BIT[2].SRL is F //synthesis attribute RLOC of BIT[3].SRL is X0Y1 //synthesis attribute BEL of BIT[3].SRL is G //synthesis attribute RLOC of BIT[4].SRL is X0Y2 //synthesis attribute BEL of BIT[4].SRL is F //synthesis attribute RLOC of BIT[5].SRL is X0Y2 //synthesis attribute BEL of BIT[5].SRL is G //synthesis attribute RLOC of BIT[6].SRL is X0Y3 //synthesis attribute BEL of BIT[6].SRL is F //synthesis attribute RLOC of BIT[7].SRL is X0Y3 //synthesis attribute BEL of BIT[7].SRL is G //synthesis attribute RLOC of BIT[8].SRL is X0Y4 //synthesis attribute BEL of BIT[8].SRL is F //synthesis attribute RLOC of BIT[9].SRL is X0Y4 //synthesis attribute BEL of BIT[9].SRL is G //synthesis attribute RLOC of BIT[10].SRL is X0Y5 //synthesis attribute BEL of BIT[10].SRL is F //synthesis attribute RLOC of BIT[11].SRL is X0Y5 //synthesis attribute BEL of BIT[11].SRL is G //synthesis attribute RLOC of BIT[12].SRL is X0Y6 //synthesis attribute BEL of BIT[12].SRL is F //synthesis attribute RLOC of BIT[13].SRL is X0Y6 //synthesis attribute BEL of BIT[13].SRL is G //synthesis attribute RLOC of BIT[14].SRL is X0Y7 //synthesis attribute BEL of BIT[14].SRL is F //synthesis attribute RLOC of BIT[15].SRL is X0Y7 //synthesis attribute BEL of BIT[15].SRL is G // RLOC the FF's // //synthesis attribute RLOC of DFF[0] is X0Y0 //synthesis attribute BEL of DFF[0] is FFX //synthesis attribute RLOC of DFF[1] is X0Y0 //synthesis attribute BEL of DFF[1] is FFY //synthesis attribute RLOC of DFF[2] is X0Y1 //synthesis attribute BEL of DFF[2] is FFX //synthesis attribute RLOC of DFF[3] is X0Y1 //synthesis attribute BEL of DFF[3] is FFY //synthesis attribute RLOC of DFF[4] is X0Y2 //synthesis attribute BEL of DFF[4] is FFX //synthesis attribute RLOC of DFF[5] is X0Y2 //synthesis attribute BEL of DFF[5] is FFY //synthesis attribute RLOC of DFF[6] is X0Y3 //synthesis attribute BEL of DFF[6] is FFX //synthesis attribute RLOC of DFF[7] is X0Y3 //synthesis attribute BEL of DFF[7] is FFY //synthesis attribute RLOC of DFF[8] is X0Y4 //synthesis attribute BEL of DFF[8] is FFX //synthesis attribute RLOC of DFF[9] is X0Y4 //synthesis attribute BEL of DFF[9] is FFY //synthesis attribute RLOC of DFF[10] is X0Y5 //synthesis attribute BEL of DFF[10] is FFX //synthesis attribute RLOC of DFF[11] is X0Y5 //synthesis attribute BEL of DFF[11] is FFY //synthesis attribute RLOC of DFF[12] is X0Y6 //synthesis attribute BEL of DFF[12] is FFX //synthesis attribute RLOC of DFF[13] is X0Y6 //synthesis attribute BEL of DFF[13] is FFY //synthesis attribute RLOC of DFF[14] is X0Y7 //synthesis attribute BEL of DFF[14] is FFX //synthesis attribute RLOC of DFF[15] is X0Y7 //synthesis attribute BEL of DFF[15] is FFY endmoduleArticle: 61614
Thanks for all of the suggestions. My solution was to change the unused pins to be configured "as inputs, tri-stated". Once I made this change, my minimal test system started working. (Which unfortunately led to the conclusion that there are additional problems in my real project ... oh well, 1 down ?? to go) I do wish the stratix tutorial at least *mentioned* this, even if it was something like, "The following settings have already been made for you in this tutorial: " with a bullet list following. That way, there would at least be an idea of where to begin searching when faced with an unknown problem. Thanks again, -PArticle: 61615
"Georg Acher" <acher@in.tum.de> wrote in message news:blujtj$bau$1@wsc10.lrz-muenchen.de... > In article <3f824f56$0$4845$afc38c87@news.optusnet.com.au>, > "Arthur Sharp" <arthur@nospam.com> writes: > <ise6.1 on Suse Linux> > |> I get the following error message : > |> Wind/U Error (294): Unable to install Wind/U ini file > |> (/media/cdrom/data/WindU). > |> See the Wind/U manual for more details on the ".WindU" file and the "WINDU" > |> environment variable. > > I have copied the whole CD to hard disk first and started the setup in that > directory. It worked on Suse8.0. If you can find out which program causes the > message (run the script with "sh -x setup"), you can add a "strace " in front of > that command. Then you'll see all performed system calls and maybe the cause for > the problem... Thaks for your suggestion, I've tried copying it on the HD, thinking it was trying to write to "data", but I got the same error message, but with a different path (/tmp/xilinx since that's where I copied it). The problem is that, in my setup script, it sets the variable WUHOME as /media/cdrom/data and then it fails, not surprisingly since /media/cdrom/data is empty !!! > |> After a while, a window appears saying "Warning : no data files were found > |> on CD image. > |> The installation will be terminated". > |> When I press ok, the installation finishes. > |> > |> The funny thing is that the directory "data" ((/media/cdrom/data/) on the > |> cdrom is empty on the CD I've got. > > The same for me. The installation images are in idata. I'm tempted to change the setup script so that it points to idata and not data. Thanks, AtrthurArticle: 61617
This is the top module. It's simple. I'm using the new attribute syntax to specify U_SETs. It's nice 'cause you can comment these out if you are experimenting. code below. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" module test( input wire clk, input wire [9:0] a, input wire [9:0] b, output reg [10:0] total ); wire [9:0] a_dly[1:0]; (* U_SET = "DLY00" *) SRL_DLY #(.WIDTH (10), .DELAY ( 2)) DLY00(.CLK(clk), .IN(a), .Q_OUT(a_dly[0]), .Q15_OUT()); (* U_SET = "DLY01" *) SRL_DLY #(.WIDTH (10), .DELAY ( 4)) DLY01(.CLK(clk), .IN(a), .Q_OUT(a_dly[1]), .Q15_OUT()); always @(posedge clk) begin total <= a_dly[0] + a_dly[1]; end endmoduleArticle: 61618
Martin Euredjian wrote: > > At the risk of sounding stupid. I can't find an EDIF (old ".edn")file > anywhere and NGD2EDIF doesn't seem to be supported any more (running > 6.1i). Where do I look? I used NGD2VER to create a simulation model. > It clearly shows one instance of the macro and two instantiations. > However, all placement info is gone, as this is a simulation model. Another reason why I try to persuade my customers to buy a copy of Synplicity. I guess you are using the X tool which bypasses EDIF. Bummer.Article: 61619
Read this first: http://www.xilinx.com/univ/beginnersbookjune2003ver2.pdf You need to read through the VirtexII data sheet: http://direct.xilinx.com/bvdocs/publications/ds031.pdf and user guide: http://direct.xilinx.com/bvdocs/userguides/ug002.pdf Then move on to the development system manuals: http://toolbox.xilinx.com/docsan/xilinx6/books/manuals.pdf probably get started with this one: http://toolbox.xilinx.com/docsan/xilinx6/books/docs/dev/dev.pdf You'll find answers to your many questions in these documents. I know, it's a lot of material. Trust me, if you don't put in the work now you'll pay for it one way or the other later on. I've never used System ACE. Did you get a JTAG cable? Get the parallel cable IV. I'm assuming you have ISE6.1i or WebPACK. Does your distributor have FAE's that can help? Call them. In general terms, you have a fairly steep learning curve in front of you. Read the above. It might give you a good overall perspective. Do you know any HDL's? Have you worked with any other FPGA's? What's your background, hardware or software? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "mintchoco" <yankiu_chan@yahoo.com> wrote in message news:ad501ab3.0310070918.5f6710b4@posting.google.com... > I have the Xilinx Virtex II Development Board sitting in front of me, > and I am completely lost and need to get started soon. I have never > worked with Xilinx FPGAs, so maybe some of you can share your > expertise. > > The board comes only with the power-adaptor for the System ACE module. > > Questions: > - How do I program the device? > - Is it through the System ACE? > - What cables do I need? > - Where do these plug into? > > Any other tips on getting stared, I'm kind of lost. > > Thanks in advance.Article: 61620
Hello I've done some work in ASIC Verilog design, but not that much in FPGA design. SO, I wonder what are the mani differences between these 2 types od design. I found a multimedia document about this on Xilinxs website, but I cannot read it on my Linux box. Do you know a web site which could give me a brief overview of the most important differences? By the way, I thought it was possible to download Xilinx 6.1 for free on their website, but I dind't find the link. Thank youArticle: 61621
Thinking about this some more, I don't think it is a hierarchy problem. That is
usually caught by the mapper complaining there are more than 2 FF/s or LUTs in a
single slice because the flattened netlist RLOCs wind up on top of each other.
I didn't see what device you are using, so the specifics may vary for what I am
going to describe below. The fact that one instance is getting placed properly
tells me the netlist going in has the placement info in it, so that is not
likely the problem either. First, check to make sure you don't have the use
RLOCs property disabled in the xilinx tools. That seems to disable some but not
all RLOCs in a hierarchical design. Assuming that is not disabled, then the
RPMs will get broken up if there is something preventing one or more of the
primitives being placed according to the RLOC.
I think you said these were SRL16's, in which case the two SRL16's packed in one
slice must share clock, and WE. If you are packing a register with the SRL, the
registers in the slice must share CE, and can't use the reset pin. If any of
these restrictions are violated, then it will break up the RPM. Also, if this is
a Spartan 3, the SRL16s must be in an even column. The synthesis may be
duplicating control signals causing different instances of the same signal to
appear on the two SRLs or FFs in the slice. You can control the segmentation of
a high fanout signal by using strategically placed keep buffers in your code
(syn_keep attribute for synplify, don't recall off hand the syntax for xilinx).
Place a buffer on high fanout control signals where they enter the lowest levels
of your hierarchy. It might look something like this:
signal lcl_ce:std_logic;
attribute syn_keep of lcl_ce:signal is true;
attribute RLOC of....
begin
lcl_ce<=ce;
This forces a keep buffer at the entrance to the RPM, which in turn regulates
how the high fanout signal gets broken up. The net result is all the primitives
in the RPM use the same branch of the signal provided the fanout limit is high
enough to accommodate all the instances in your RPM. If you don't have a clock
buffer, the clocks can be broken up too, so make sure your design either has a
clock buffer, or has a high enough fanout limit to keep from breaking up the
clock into a tree.
BTW, this is a heckuva lot easier in VHDL with the generate statements. With
VHDL you can convert the generate index variable to a string constant to form
the attribute string. I don't know of a way to do that in verilog. For VHDL,
the code might look like:
L:for i in 0 to width-1 generate
constant rloc_str : string := "R" & itoa( origin -(i/2)) & "C0" & ".S" &
itoa(slice mod 2);
signal l,d,qr,qs: STD_LOGIC;
attribute BEL of U1:label is bel_lut(i mod 2);
attribute RLOC of U1 : label is rloc_str;
Martin Euredjian wrote:
> This is the top module. It's simple. I'm using the new attribute syntax to
> specify U_SETs. It's nice 'cause you can comment these out if you are
> experimenting.
>
> code below.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_" = "martineu"
>
> module test(
> input wire clk,
> input wire [9:0] a,
> input wire [9:0] b,
> output reg [10:0] total
> );
>
> wire [9:0] a_dly[1:0];
>
> (* U_SET = "DLY00" *)
> SRL_DLY #(.WIDTH (10), .DELAY ( 2)) DLY00(.CLK(clk), .IN(a),
> .Q_OUT(a_dly[0]), .Q15_OUT());
> (* U_SET = "DLY01" *)
> SRL_DLY #(.WIDTH (10), .DELAY ( 4)) DLY01(.CLK(clk), .IN(a),
> .Q_OUT(a_dly[1]), .Q15_OUT());
>
> always @(posedge clk) begin
> total <= a_dly[0] + a_dly[1];
> end
>
> endmodule
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 61622I'm working on a design that's using multiple DCMs along with DDR i/o registers. The main input clock is 500MHz going into a DCM with the CLKIN_DIVIDE_BY_2 flag set so it's immediataly cut down to 250MHz. The DCMs used in the design also have CLKOUT_PHASE_SHIFT=VARIABLE. To drive my DDR i/o flops, I'm currently using both the CLK0 and CLK180 pins (running at 250MHz). The original designer flowed the DDR data though the chip using both clock edges, ie, the incoming "posedge" data went down a "posedge" data pipeline to flow back out the DDR output. The incoming "negedge" data went down a "negedge" pipeline. The original design did NOT use CLK0 and CLK180 for these two data paths. Instead, the designer used "posedge" and "negedge" in the Verilog. The major problem comes in the control and data signals that cross the two domains. Because of the potential duty cycle degradation, the P&R tools don't achieve timing closure consistently. As an experiment, I changed the design to use CLK0 and CLK180 for the internal flops. I was: a) pleased when the P&R timing was better b) surprised when the design no longer worked. I figured I screwed up converting the pos/negedge vs CLK0/CLK180 conversions, so I tripple checked the design and didn't find anything. I backed up to a older working version, made the changes again being VERY careful in my conversion. Again, no luck. Timing number look good, the design doesn't work. Is there something odd in the phasing between the the posedges of CLK0 and CLK180? Anyone else run into something like this? Thanks, John ProvidenzaArticle: 61623
If the input clock has too much jitter these will exhibit jitter and
skew. Good shot that is what is biting you.
John Providenza wrote:
> I'm working on a design that's using multiple DCMs along
> with DDR i/o registers. The main input clock is 500MHz
> going into a DCM with the CLKIN_DIVIDE_BY_2 flag set
> so it's immediataly cut down to 250MHz. The DCMs used in
> the design also have CLKOUT_PHASE_SHIFT=VARIABLE.
>
> To drive my DDR i/o flops, I'm currently using both the CLK0 and
> CLK180 pins (running at 250MHz).
>
> The original designer flowed the DDR data though the chip using
> both clock edges, ie, the incoming "posedge" data went down a
> "posedge" data pipeline to flow back out the DDR output. The
> incoming "negedge" data went down a "negedge" pipeline. The
> original design did NOT use CLK0 and CLK180 for these two
> data paths. Instead, the designer used "posedge" and "negedge"
> in the Verilog. The major problem comes in the control and
> data signals that cross the two domains. Because of the potential
> duty cycle degradation, the P&R tools don't achieve timing
> closure consistently.
>
> As an experiment, I changed the design to use CLK0 and CLK180 for
> the internal flops. I was:
> a) pleased when the P&R timing was better
> b) surprised when the design no longer worked.
> I figured I screwed up converting the pos/negedge vs CLK0/CLK180
> conversions, so I tripple checked the design and didn't find
> anything. I backed up to a older working version, made the changes
> again being VERY careful in my conversion. Again, no luck. Timing
> number look good, the design doesn't work.
>
> Is there something odd in the phasing between the the posedges of
> CLK0 and CLK180?
>
> Anyone else run into something like this?
>
> Thanks,
>
> John Providenza
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 61624> > By the way, I thought it was possible to download Xilinx 6.1 for free on > their website, but I dind't find the link. I believe it's Xilinx ISE Webpack that's free. Here is the link http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=ISE+WebPack Jim Wu jimwu88NOOOSPAM@yahoo.com (remove capital letters) http://www.geocities.com/jimwu88/chips
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