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
rtArticle: 45551
hey The problem is due to the fact that u have LOCed the clock to a dedicated clock pin. Remove the constraint and it works well, though with morw delays. Better way to do is to instaniate a BUFGDLL for the external clock and connect the output to the core clk. Anjan "BROTO Laurent" <lbroto@free.fr> wrote in message news:<3d4026fa$0$10517$626a54ce@news.free.fr>... > Hi! > I've succed to synthetize opencore PCI IP Core and now I try to do a top > with this core and another one. > I can synthetize without problem but when webpack try to map this top, I get > the following error: > > ERROR:Pack:1107 - Unable to combine the following symbols into a single IOB > component: > PAD symbol "CLK" (Pad Signal = CLK) > BUF symbol "CLK_IBUF" (Output Signal = CLK_IBUF) > Each of the following constraints specifies an illegal physical site for > a > component of type IOB: > Symbol "CLK" (LOC=C11) > Please correct the constraints accordingly. > Problem encountered during the packing phase. > > I would like to know how can I solve this problem. > > Thanks, > > BROTO LaurentArticle: 45552
Since the original poster's target application is PCI, you
cannot use Spartan-II's DLL because,
1) Spartan-II DLL's minimum input frequency is 25MHz, but in PCI, it can
be less than 25MHz.
2) The clock frequency can change in PCI (At least that's what the
specification says.).
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Anjan wrote:
>
> hey The problem is due to the fact that u have LOCed the clock to a
> dedicated clock pin. Remove the constraint and it works well, though
> with morw delays. Better way to do is to instaniate a BUFGDLL for the
> external clock and connect the output to the core clk.
> Anjan
Article: 45553Make sure you are using the correct package/pin combination. For example, if you are using Spartan-II PQ208 package, and specifying, NET "CLK" LOC = "C11"; Will result in an error message because such a pin doesn't exist in a PQ208 package. Assuming you are using a Spartan-II FG456 package, pin C11 sounds like it is one of the GCLK pin, but in case you are using Spartan-II PQ208 package, I think the pin for CLK will be P185 (That's the pin location my Insight Electronics Spartan-II 150 PCI card uses.). NET "CLK" LOC = "P185"; Kevin Brace (In general, don't respond to me directly, and respond within the newsgroup.) BROTO Laurent wrote: > > Hi! > I've succed to synthetize opencore PCI IP Core and now I try to do a top > with this core and another one. > I can synthetize without problem but when webpack try to map this top, I get > the following error: > > ERROR:Pack:1107 - Unable to combine the following symbols into a single IOB > component: > PAD symbol "CLK" (Pad Signal = CLK) > BUF symbol "CLK_IBUF" (Output Signal = CLK_IBUF) > Each of the following constraints specifies an illegal physical site for > a > component of type IOB: > Symbol "CLK" (LOC=C11) > Please correct the constraints accordingly. > Problem encountered during the packing phase. > > I would like to know how can I solve this problem. > > Thanks, > > BROTO LaurentArticle: 45554
I've got a Spartan II FG456 and I've specified NET "CLK" LOC="C11". "Kevin Brace" <killspam4kevinbraceusenet@killspam4hotmail.com> a écrit dans le message news: ahqp2t$cg1$1@newsreader.mailgate.org... > Make sure you are using the correct package/pin combination. > For example, if you are using Spartan-II PQ208 package, and specifying, > > NET "CLK" LOC = "C11"; > > > Will result in an error message because such a pin doesn't exist in a > PQ208 package. > Assuming you are using a Spartan-II FG456 package, pin C11 sounds like > it is one of the GCLK pin, but in case you are using Spartan-II PQ208 > package, I think the pin for CLK will be P185 (That's the pin location > my Insight Electronics Spartan-II 150 PCI card uses.). > > NET "CLK" LOC = "P185"; > > > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.) > > > > BROTO Laurent wrote: > > > > Hi! > > I've succed to synthetize opencore PCI IP Core and now I try to do a top > > with this core and another one. > > I can synthetize without problem but when webpack try to map this top, I get > > the following error: > > > > ERROR:Pack:1107 - Unable to combine the following symbols into a single IOB > > component: > > PAD symbol "CLK" (Pad Signal = CLK) > > BUF symbol "CLK_IBUF" (Output Signal = CLK_IBUF) > > Each of the following constraints specifies an illegal physical site for > > a > > component of type IOB: > > Symbol "CLK" (LOC=C11) > > Please correct the constraints accordingly. > > Problem encountered during the packing phase. > > > > I would like to know how can I solve this problem. > > > > Thanks, > > > > BROTO LaurentArticle: 45555
sounds to me like your tools dont think your clock is a clock, just for fun: map your clock signal to an output test pin. then retry the synthesis. "BROTO Laurent" <lbroto@free.fr> wrote in message news:3d4026fa$0$10517$626a54ce@news.free.fr... > Hi! > I've succed to synthetize opencore PCI IP Core and now I try to do a top > with this core and another one. > I can synthetize without problem but when webpack try to map this top, I get > the following error: > > ERROR:Pack:1107 - Unable to combine the following symbols into a single IOB > component: > PAD symbol "CLK" (Pad Signal = CLK) > BUF symbol "CLK_IBUF" (Output Signal = CLK_IBUF) > Each of the following constraints specifies an illegal physical site for > a > component of type IOB: > Symbol "CLK" (LOC=C11) > Please correct the constraints accordingly. > Problem encountered during the packing phase. > > I would like to know how can I solve this problem. > > Thanks, > > BROTO Laurent > > >Article: 45556
Dmitri Katchalov a écrit :
> Hi,
>
Hi Dimitri,
> ...
> Now the questions.
>
> * Am I on the right track?
As you know what you want you could express it directly:
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.NUMERIC_STD.all;
...
signal IN1, IN2: UNSIGNED(8 downto 0);
signal CIN: NATURAL range 0 to 1;
...
IN1 <= '0' & A;
IN2 <= '0' & B when ADD = '1' else
'1' & not B;
CIN <= 0 when ADD = '1' else
1;
Y <= STD_LOGIC_VECTOR(IN1 + IN2 + CIN);
>
> * I'm trying to describe purely combinatorial logic here. The
> output is supposed to be the same fixed boolean function of inputs
> no matter how it is described. Why such big variations (more than
> 2 times the area)? Is this a problem with the tool or they all
> like that?
They're all like that.
> * What's the story with IEEE.std_logic.SIGNED vs .UNSIGNED? I
> heard that they are are mutually exclusive and math operations
> produce different results depending on which one is in use.
> Webpack automatically inserts IEEE.STD_LOGIC_UNSIGNED.ALL at the
> beginning of every VHDL source it creates. Should I always use
> UNSIGNED?
use IEEE.NUMERIC_STD instead of all these non-standard packages.
Regards,
--
Renaud Pacalet, ENST / COMELEC, 46 rue Barrault 75634 Paris Cedex 13
Tel. : 01 45 81 78 08 | Fax : 01 45 80 40 36 | Mel : pacalet@enst.fr
Article: 45557dmitrik@mailandnews.com (Dmitri Katchalov) wrote in message news:<3db7c986.0207250834.7ae051c6@posting.google.com>... > Hi, > > I'm new to FPGA. I'm trying to replicate PIC16Fxxx core as an exersize > (any real programmer should write at least one OS and compiler :) > > I'm trying to synthesize a simple ALU. I'm using VHDL and XST (WebPack). I would suggest you to work a bit level. Create a bit cell able to perform all the operation, not only add and subtract. The bit cell will have two inputs A and B for operands, one input Cin for carry-in, two inputs S0 and S1 to select the operation, one output for result and one for Cout (carry out). Basically, you need a 4 inputs mux with two selection bits. The inputs of the mux will be A – used for NOPs and other instruction which don’t change the Accumulator A or B – used for OR instruction and set bit instruction A and B – used for AND instructions and clear bit instructions A xor B used for XOR, ADD and SUB (if you apply an inverted operand at the input B and set Cy to 1 if no borrow). I didn’t enter in details (you should use also Generate and Propagate signals for speed, you should think how two make rotate and shift, bit operations and test bit operations), I just want to suggest to use a structural description rather than a behavioral one if you want to optimize the design. Regards, AdrianArticle: 45558
Hello All,
This version has many new features and improvements. The nice thing
from a user stand point, is that it doesn't expire and a password is no
longer
needed.
As always, comments and suggestions welcome.
info@timinganalyzer.net
The website is:
www.timinganalyzer.net
----------------------------------------------------------------------------
---
Version 0.72
New Features and Improvements
1 The license has changed. The TimingAnalyzer is free for personal and
academic use. As a result, the beta versions do not expire or require
a password anymore.
2 Delays, Constraints, DTTs, and StateBars use edge positions now.
Previously, all edges where set to the 50% position. Now, any
position in the edges can be used. The edge time occurs now at
the edge position. For example: If you add an edge at 100ns and
the edge position is set to 20%, then the time of edge at the
20% point is 100ns. All vertical lines now go completely through
the signal.
3 Delay, Constraint, and DTT time can be displayed now as an option
instead of the labels. See "Options-View Times" menu.
4 Updated MC68LC302 Microcontroller and MC68000 Microprocessor
scripts to use new edge position capabilities. Now the
timing diagrams show actual edge rise and fall times with
delays specified by the manufacturer where necessary at the
20% and 80% positions.
5 The execute scripts dialog now contains a listbox of all the
script files located in the script directory so it is easier
to select and execute scripts.
6 All drawing functions now use Java2D Graphics. Previously, dashed
lines used in drawing constraints, delays, DTTs, and StateBars were
drawn as line segments. Now lines styles can be set with strokes so
dashed lines and varying width solid lines can be used.
7 Added Text and Line draw Antialiasing enables in the global options.
This smooths line draws and produces higher quality text and lines.
Performance is sacrificed for these so they can be disabled in the
global options dialog.
8 Added Look and Feel Themes. The user can save the current look and
feel of the timing diagram as a theme. The theme file is stored in
the
themes directory under the install directory. Included are themes
for printing color images and B&W images, or viewing / editing timing
diagrams. When a new theme is selected, the theme file is saved as
the
current td_defaults file. You can switch themes quickly. Image
diagram
options have been eliminated since they are no longer needed.
9 Improved bus value dialog. Now the bus value format ( Hex, Bin, Dec,
or
Text ) and the number of bits are used when setting a new bus value.
Any bus values are checked to be a valid number for the selected
format and bus width.
10 Increment and Decrement the bus value. Use Ctrl + and Ctrl - to inc
and dec the bus value shown in the status bar. If bus values are
selected
in a signal, they will be affected. All changes are bus width and
number
format accurate. This is nice for incrementing addresses or data
values
in a bus or changing the output of a counter or shift register.
11 Snap to Edge. This is nice when building synchronous signals from
other
signals like clocks. When enabled, adding a new edge occurs at the
closest
edge time in the snap signal. Use key s to set the selected signal to
the
snap signal. Use this with "Invert Next State" enabled to quickly
build
new synchronous signals. See "Options-Edges" menu.
Article: 45559I love my F5 muxes! Synplify does a decent job of inferring them (less common in general logic, more common in multiplexers). It's nice to have a decode of the form register[index[2:0]] and get it all into one CLB with some MUXF5 and MUXF6 elements. Bigger multiplexers just use more than one stage of these. Heck, in the Virtex type parts I instantiate a "rotator" that uses cross-coupled F6 muxes to give me a barrel rotate kind of functionality with (more than) twice the efficiency of the standard multiplexers alone. I'm just a little sad the Virtex-II doesn't cross-couple the MUXF6 elements - I have to use a MUXF8 to use that same technique! Less efficiency overall. Ahhh, esoteric design techniques . . . turning a 64 bit barrel shifter from 192 slices to about 66 with one fewer levels of logic. Not for everyone but fun for many. - John_H MUXFn afficionado Kevin Brace wrote: > I suppose, when BX or BY input is tied to a FF, it looks like to me you > won't be able to use an F5MUX (A multiplexer that ties two 4-input LUTs > to recreate a 4:1 MUX or a 5-input LUT.), but since most synthesis tools > cannot seem to take advantage of F5MUX anyway, that shouldn't be a huge > penalty. > I do wonder, does anyone use F5MUX? > Perhaps, shouldn't Xilinx get rid of it?Article: 45560
I am reaching back now, but I seem to remember that when it came to implementing muxes the Altera parts (maybe only the 10K parts) have a "cascade" backbone in each group of LEs that allows them to do very fast muxes as well as AND-OR or just wide AND type logic. The cascade logic is a two input AND (or is it an OR?) gate that combines the cascade input with the LUT output. Although the delays are additive, they are very short like a carry chain and can frequently beat an equivalent tree mux. But to use the cascade chain for a mux you need to change your logic to use decoded enables rather than encoded selects. The number of LEs for the mux then becomes N/2 where N is the number of inputs. This can be very optimal for wide word muxes where the decoding the enables uses much less logic than what is saved in the mux. I don't remember Synplify doing a great job of synthesis with these structures. It may have worked well if you used a particular coding style. But otherwise it would only use two LEs instead of the four or five that were optimal. John_H wrote: > > I love my F5 muxes! Synplify does a decent job of inferring them (less > common in general logic, more common in multiplexers). It's nice to have a > decode of the form register[index[2:0]] and get it all into one CLB with > some MUXF5 and MUXF6 elements. Bigger multiplexers just use more than one > stage of these. Heck, in the Virtex type parts I instantiate a "rotator" > that uses cross-coupled F6 muxes to give me a barrel rotate kind of > functionality with (more than) twice the efficiency of the standard > multiplexers alone. I'm just a little sad the Virtex-II doesn't > cross-couple the MUXF6 elements - I have to use a MUXF8 to use that same > technique! Less efficiency overall. > > Ahhh, esoteric design techniques . . . turning a 64 bit barrel shifter from > 192 slices to about 66 with one fewer levels of logic. Not for everyone but > fun for many. > > - John_H > MUXFn afficionado > > Kevin Brace wrote: > > > I suppose, when BX or BY input is tied to a FF, it looks like to me you > > won't be able to use an F5MUX (A multiplexer that ties two 4-input LUTs > > to recreate a 4:1 MUX or a 5-input LUT.), but since most synthesis tools > > cannot seem to take advantage of F5MUX anyway, that shouldn't be a huge > > penalty. > > I do wonder, does anyone use F5MUX? > > Perhaps, shouldn't Xilinx get rid of it? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 45561
Thank You Ray, I know the number of LEs in Altera but may go out to get a Xilinx prototype board. Hence I wanted a rough idea on what device in Xilinx would fit my application. And you provided that info. Thanks, Prashant Ray Andraka <ray@andraka.com> wrote in message news:<3D409F03.678206DA@andraka.com>... > Each Altera LE is basically a 4 input LUT plus a D flip-flop. In the > current Xilinx families (excluding the 4000/spartanI series), there are > 2 four input LUTs per slice, so a rough equivalence is two Altera LEs > per Xilinx slice. That is only part of the story though, each family > has features, that if you take advantage of them can tip the balance. > The Xilinx slices shine in DSP type applications because the arithmetic > is more robust and because the LUT can be used as a 16 bit shift > register instead of logic. The arithmetic robustness comes from the > fact that the Altera 4 LUTis decimated into a pair of 3-LUTs when used > in arithmetic mode (one ofr sum one for carry), where Xilinx has > separate dedicated carry logic. The result is that you can pack more > function into one level of logic. Xilinx also has some extra > multiplexers that select LUT outputs to get larger muxes for almost free > (although, they do not match the bit pitch of arithmetic, so they can be > of limited value in high performance arithmetic circuits). > > Some Altera devices have CAM memory, and the "DSP block" in stratix > looks like it will make stiff competition for VIrtexII. > > The easiest way is to count LUTs, but paying attention to how arithmetic > gets implemented and to potential use of SRL16s. > > Prashant wrote: > > > Hi, > > I have the LE count of a design in Altera's Apex20KE1500E device. I > > need to know what Xilinx device will this design fit in. Is there a > > relationship between the logic elements of Altera and logic cells of > > Xilinx ? How can one decide which exact Xilinx device to use without > > having to compile the design on a Xilinx device ? > > > > Thanks, > > Prashant > > -- > --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, 1759Article: 45562
"Doug Wilson" <doug_wilson@3mtsNOSPAM.com> wrote in message news:<ee780cf.-1@WebX.sUN8CHnE>... > If I have two separate boards in a system, each with a VirtexII > DCM used in frequency synthesis mode, both generating the same > frequency, is there anything I can do with the DCM rst line > (or anything else) to ensure that they come up in phase or is > it impossible to guarantee the phase? Howdy Doug, Considering Xilinx won't guarantee the output phase of the DV outputs of two DCMs in the same device (I asked. Twice), there is no chance it will automagicly do it across devices. If you have any spare lines between the FPGA's, you can come up with a circuit to do a phase compare and invert if need be, or you can simply feed the synthesised frequency from one device to the other. If you have nothing between the FPGA's, you're SOL. MarcArticle: 45563
The carry chain in the Xilinx part can do the same thing as the Altera cascade chain if I recall correctly. If the Xilinx MUXCY element passes a 1 on the carry and a zero when the LUT result is false, you get a wide AND cascade chain. Wide word muxes can still take N/2 LUTs in the Xilinx architecture independent of which method you use. The cascade chain would probably need a manual instantiaton in Xilinx, possibly in Altera. A 4-1 mux ends up being the same in either architecture, really: 2 LUTs. The rotator I was talking about ends up beating out the cascade approach significantly in either architecture. rickman wrote: > I am reaching back now, but I seem to remember that when it came to > implementing muxes the Altera parts (maybe only the 10K parts) have a > "cascade" backbone in each group of LEs that allows them to do very fast > muxes as well as AND-OR or just wide AND type logic. The cascade logic > is a two input AND (or is it an OR?) gate that combines the cascade > input with the LUT output. Although the delays are additive, they are > very short like a carry chain and can frequently beat an equivalent tree > mux. > > But to use the cascade chain for a mux you need to change your logic to > use decoded enables rather than encoded selects. The number of LEs for > the mux then becomes N/2 where N is the number of inputs. This can be > very optimal for wide word muxes where the decoding the enables uses > much less logic than what is saved in the mux. > > I don't remember Synplify doing a great job of synthesis with these > structures. It may have worked well if you used a particular coding > style. But otherwise it would only use two LEs instead of the four or > five that were optimal.Article: 45564
Ray, In 5.1i the FF will still be broken out to a new H_SET, but the RLOC_ORIGIN is no longer dropped. It gets converted to a COMP LOCATE constraint in the PCF for a slice component containing the FF. So you still need to apply the RLOC_ORIGIN at the top pf the H_SET hierarchy to get what you want. BTW, another way to locate your macro without having to deal with the RLOC_ORIGIN attribute at all is to just put the following constraint in the PCF file. If it's outside the SCHEMATIC START/SCHEMATIC END section, Map won't overwrite it. MACRO "hset" LOCATE = SITE "SLICE_X41Y24" LEVEL 1; Bret Ray Andraka wrote: > Bret, > > Thanks for your reply. I generally use the default HSETs > because it is considerably less effort than working with the > explicit sets, especially if you have code that is reused > among many projects (the RLOCs are embedded in the VHDL > source). It is interesting to note that the floorplanner, > if used with the ucf flow puts the RLOC ORIGIN constraint at > the bottom of the hierarchy as well, which is where I got > the particular RLOC_ORIGIN to begin with. I hadn't realized > that putting the RLOC origin on an element that is not at > the top level of the hset would create a new hset. Anyway, > the problem is now solved. > > Does putting the RLOC Origin lower in the hierarchy work in > 5.1 then? > > Bret Wade wrote: > > > > > > > Ray Andraka wrote: > > > >> I tried the RLOC origin on a smaller macro in the > >> design, and it works fine > >> in that case. The failing macro has tiles which come > >> from a different edif > >> netlist. It is a fairly large macro as well (24x80 > >> slices). The size > >> and/or the fact that its netlist comes from nested edif > >> files may be > >> contributing factors. The odd thing is that the > >> RLOC_ORIGIN is recognized > >> in the editable view of the floorplanner (which pulls > >> it's info from the ucf > >> and ngd files), but is being ignored in place and route. > > > > Hello Ray, > > > > I've taken a look at your design and have found two > > factors contributing to the vanishing RLOC_ORIGIN > > constraint: > > > > 1. Your macro specification is using the default H_SET set > > grouping. It turns out that the RLOC_ORIGIN is itself used > > to define sets and because you are applying it to a FF at > > the bottom of the hierarchy, that FF is being broken out > > into a separate single component macro, which I assume is > > not your intention. The solution which has been > > communicated to you by the hotline, is to move the > > RLOC_ORIGIN constraint to the hierarchy level that is the > > start of your H_SET. Another solution would be to apply > > HU_SET constraints to all of the instances you do want in > > the macro rather that relying on the implied H_SET > > grouping. > > > > From the constraints guide: > > All design elements with RLOC constraints at a single node > > of the design hierarchy are considered to be in the same > > H_SET set unless they are tagged with another type of set > > constraint such as RLOC_ORIGIN or RLOC_RANGE. If you > > explicitly tag any element with an RLOC_ORIGIN, > > RLOC_RANGE, U_SET, or HU_SET constraint, it is removed > > from an H_SET set. Most designs contain only H_SET > > constraints, since they are the underlying mechanism for > > relationally placed macros. The RLOC_ORIGIN or RLOC_RANGE > > constraints are discussed further in the "Fixing Members > > of a Set at Exact Die Locations" section. > > > > 2. There is a known problem in 4.2i where RLOC_ORIGIN > > constraints on single component RPMs are dropped. This > > problem is described in Xilinx Answer 12192. This explains > > why the RLOC_ORIGIN constraint did not result in a > > corresponding MACRO LOCATE constraint in the PCF file. > > This problem has been fixed in version 5.1i. I have > > confirmed that using your design > > > > Regards, > > Bret Wade > > Xilinx Product Applications > > -- > --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, 1759Article: 45565
Hear! hear!
Goran speaks the the truth here. This is why a large part of our internal library is
structurally instantiated.
The trouble with an add/sub with carry-in is that for subtraction you need to do A +
!B +1, which means the +1 has to go into the carry chain as the carry in, so you'll
have trouble making that work in 1 level of logic unless you do the +1 in other logic
either before or after the add/sub stage.
The trick to getting the synth to produce what you want most of the time is to code
it up with a structure exactly mimicking the slice, which is to say code it so that
you do any muxing etc in front of the add:
B_inv<= B when sub='1' else not B;
cin <= 1 when sub='1' else 0;
d<= A + Binv + cin;
If need be, you can put syn_keeps on the inputs of that logic to keep the synth
honest.
Goran Bilski wrote:
> Hi Dimitri,
>
> Believe me, I have been there and I couldn't find a nice way to do what I wanted.
>
> Which was a add/sub with carry-in and carry-out.
> I spend a day trying all sorts of way to express that but only ended up with half
> solutions.
> Then I just instanciated LUT, MUXCY and XORCY using a generate loop.
> That took me 5 min to code which it's way faster than trying to foul the tools.
>
> I have found out that if I have to go around the synthesize tool by changing my
> code,
> it's way faster to just instanciated what I want.
> That also gives me the possibility to RLOC the components and do even more stuff
> using the MULT_AND
> and set/reset on the DFFs.
>
> Göran
>
> Dmitri Katchalov wrote:
>
> > Hi,
> >
> > I'm new to FPGA. I'm trying to replicate PIC16Fxxx core as an exersize
> > (any real programmer should write at least one OS and compiler :)
> >
> > I'm trying to synthesize a simple ALU. I'm using VHDL and XST (WebPack).
> > Target is SpartanIIE. It sortof works but is rather inefficient.
> > At first I tried a big case statement for all ALU operations.
> > XST happily infers lots of built-in macros (one for each ALU op)
> > and a huge output mux. For example it produces 6 carry-chain adders
> > (one for each ADD, SUB, INC, DEC and another two to get the
> > half-carry bit for ADD/SUB) where I would think one is enough.
> >
> > I've narrowed the problem down to a simple adder/subtractor:
> >
> > if add='1' then
> > Y <= A + B;
> > else
> > Y <= A - B;
> > end if;
> >
> > This works fine, produces a single 8-bit adder/subtractor. 4 slices in total.
> > But this does not give me carry/borrow bit.
> >
> > if add='1' then
> > Y <= ('0' & A) + ('0' & B);
> > else
> > Y <= ('0' & A) - ('0' & B);
> > end if;
> >
> > produces 8bit adder with carry-out, a separate 9bit subtractor and
> > a 9bit 2x1 mux. 9 slices. I tried different variations of the above
> > with the same results.
> >
> > Finally I have come up with the following code.
> > It uses the fact that A-B = A +(-B) = A + ((not B) + 1).
> >
> > variable tmp: integer;
> > variable cin: std_logic;
> >
> > if op = '1' then
> > tmp := conv_integer(B);
> > cin := '0';
> > else
> > tmp := conv_integer(not B);
> > cin := '1';
> > end if;
> >
> > Y <= conv_std_logic_vector(conv_integer(A) + tmp + conv_integer(cin),9);
> >
> > This infers 1 "9bit adder carry in" and 8 2x1 muxes and takes only 4 slices.
> > Much better. One small detail: if I declare cin as integer instead
> > of converting it from std_logic at the last step, I'm back to 9 slices.
> >
> > Now the questions.
> >
> > * Am I on the right track?
> >
> > * I'm trying to describe purely combinatorial logic here. The output
> > is supposed to be the same fixed boolean function of inputs no matter
> > how it is described. Why such big variations (more than 2 times the area)?
> > Is this a problem with the tool or they all like that?
> >
> > * Should I be tweaking XST settings instead? Is there a magic setting
> > like "Do what I mean not what I say" :)
> >
> > * Xilinx lib has "8bit adder carry out" but it doesn't seem to have
> > "8bit subtractor borrow out". Is this right?
> >
> > * How do I get the half-carry bit out of the 8bit adder? I guess I can
> > instantiate/infer two separate 4bit adders. Is there a better way?
> >
> > * What's the story with IEEE.std_logic.SIGNED vs .UNSIGNED? I heard that
> > they are are mutually exclusive and math operations produce different
> > results depending on which one is in use. Webpack automatically inserts
> > IEEE.STD_LOGIC_UNSIGNED.ALL at the beginning of every VHDL source it
> > creates. Should I always use UNSIGNED?
> >
> > * Is there a decent on-line reference for all those IEEE.* libraries?
> > I've found several good VHDL tutorials but none of them covers
> > std_logic in details.
> >
> > Thanks,
> > Dmitri
--
--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: 45566
I am not too familiar with what Opencores.org PCI IP core does
with I/O pads, but assuming that it is not doing something strange, XST
should normally automatically infer IBUFG and BUFG for the clock pin.
Make sure "Add I/O Buffer" option is checkmarked.
If the previous tip didn't work, you should directly instantiate IBUFG
and BUFG library primitives from the source code.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
BROTO Laurent wrote:
>
> I've got a Spartan II FG456 and I've specified NET "CLK" LOC="C11".
>
> > Kevin Brace (In general, don't respond to me directly, and respond
> > within the newsgroup.)
> >
> >
> >
Article: 45567
If you haven't got responses, you may do better by contacting the regulars
on this group directly, or at least those who are doing consulting. You
might also check the Xilinx or Altera websites for their listings of
expert consultants.
Peter Boot wrote:
> I need someone to do a small design and prototype building job using a
> Programmable Gate Array. I am in Sydney Australia please email me at
> peter.boot@ihug.com.au
--
--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: 45568>> Interstingly, according to one web page, they used a LFSR as the PC, so >> consecutive instructions were all over the place in the memory. > > Wow - and not so silly, when you think more about it : > The 'linker' can manage code shuffles, and a LFSR is both >silicon frugal and fast. In the old days (15-20 years ago), it was common to build small microcoded state machines out of TTL chips. Speedwise, ROMs were well matched to ALU chips so the system was ballanced. Most of the systems I worked on used wide instructions to simplify instruction decoding. Decoding takes logic and you get a lot of the right type of logic in a ROM chip so it's a reasonable space tradeoff as well as not adding decoding delays to the critical path. Usually, each instruction included a next-PC field. Branching was done by ORing bits into the bottom of the next-PC. The assembler did all the work of assigning addresses. It's not a bit deal to build and assembler for a new system if you have one to copy. This style of architecture might make sense in an FPGA if you have RAM/ROM available and a problem that works well as firmware/microcode. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 45570
> - theoretical : if i have a PCI-bus w/o real 5V-PCI-devices i can use > Virtex-E out of danger. > Do you think thats right ? I think the answer depends upon how many you want to build and who is going to be using them. Several years ago, I had the same problem. I put a scope on the system I was interested in running in. I didn't see any reflections significantly over 3 V. We decided it was a risk we were willing to take. We were only going to build a handful of cards for a specific project. We were not going to sell them to anybody. We didn't have to worry about support or users abusing our gear. Note that you have to get out your scope (or take your chances) every time you want to plug a new PCI card into your system. (And maybe every time you move a card.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 45571
Thanks guys, I could fix the problem, I am getting zero hold time. The problem was I wasn't using dedicated clk. This was because map was failing if I associate a clk pin to the coregen module. So I put a BUFGDLL and it works Anjan Kevin Brace <killspam4kevinbraceusenet@killspam4hotmail.com> wrote in message news:<ahqcbd$8sk$1@newsreader.mailgate.org>... > Assuming that you don't know much about hold time (I didn't have > a good understanding of hold time myself only a few months ago. So, > someone correct me if I am wrong.), having hold time (positive hold > time) means that the input signal is reaching the FF before the clock > edge is striking the FF. > So, to prevent the input signal from reaching the FF too early, what you > will have to do is to put some delay between the input pin and the FF > input (Slowing down the signal.). > If the input signal is reaching the FF after the clock strikes, then you > are having zero or negative hold time, which is what you want. > Use of IOB input FF should solve the hold time problem you are talking > about, even if you don't use a built-in DLL, because IOB's input FF has > some programmable delay that's greater than the GCLK's clock > distribution delay. > Also, is the clock coming in through a dedicated GCLKx pin? > If not, that might make the hold time problem worse because the clock > distribution delay will be large compared to using the dedicated GCLKx > pin. > > > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.) > > > > Anjan wrote: > > > > I am interfacing a DSP to xilinx fpga. The DSP writes to a fifo in the > > fpga. The timing report gives very good setup time but large hold > > time. The DSP doesn't introduce hold time but can have wait states. > > Can any one suggest a way in which I can reduce the hold time > > requirement. > > AnjanArticle: 45572
hello all i just wanted to know that can 555 be used for cplds as clock input if the frequency is very low something like 1 hz. regardsArticle: 45573
"suchitra" <ssbhide@rediffmail.com> schrieb im Newsbeitrag news:110cc2fe.0207262205.2e37143c@posting.google.com... > hello all > i just wanted to know that can 555 be used for cplds as clock input if > the frequency is very low something like 1 hz. Hmm, the datasheet says something about 100..300ns rise/fall time. This is terrible slow for a FPGA. You should use a 74xx14 (schmitt-trigger) after the NE555 to get fast edges. -- MfG FalkArticle: 45574
should be ok. I've done it with EP7064. Martin "suchitra" <ssbhide@rediffmail.com> schrieb im Newsbeitrag news:110cc2fe.0207262205.2e37143c@posting.google.com... > hello all > i just wanted to know that can 555 be used for cplds as clock input if > the frequency is very low something like 1 hz. > regards
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