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
I too was recently a newbie to the Xilinx Webpack software, but found it to be a fiarly good piece of software. The problem you are having with the constraint editor, I believe is due to the changes you have made to your design not being saved. Make sure you save any design/code chages before entering the constraint editor. Also if you have removed pins from the design/code you will have to manually edit the constraint file to remove them. Normally one would do most of thier design and allow the software to do as it pleases, then lock the design, then use the constraint editor. Once you have used the constraint editor, keep in mind that you are essentially working with a locked design, and may have to manually edit changes. Hope this helps and doesn't confuse things too much. - Troy Børge Strand wrote: > Is it just me, or can the WebPack icon "Edit Implementation Constraints > (Constraints Editor)" be a little touchy? > > I'm really a novice when it comes to FPGA programming, so having somewhere > to point and click is a nice start. But when I add new signals (which I want > to map to pins) to my source code, they don't appear in the list in the > Constraints Editor. Initially, in a brand new project, it finds several > signals and lets me assign pins to them. But as I keep working, making the > Constraints Editor find, and not least save, my signals gets increasingly > difficult. > > When I add a signal/pin in my source code, and the Constraints Editor fails > to see it, I rather edit the ucf file. If I hit the Constraints Editor again > after updating the ucf, the constraints editor refuses to start, stating > that my newly added signal does not exist. > > I'm all ears if you have any suggestion regarding what I should do about the > Constraints Editor. I'd like to use it if I could only find it trustworthy. > But the best thing would be to put the constraints into my verilog code. I > mean, your modules could go with a verilog testbench for simulation and a > verilog constraints file for implementation. > > > Regards, > > Børge > > > The error message and code are inserted below. > > ERROR:NgdBuild:397 - Could not find NET 'resetl' in design 'implementation'. > NET entry is 'NET "resetl" LOC = "D8"; > ' > ERROR:Parsers:11 - Encountered unrecognized constraint while parsing. > ERROR:NgdBuild:19 - Errors found while parsing constraint file > "implementation.ucf". > > > while the top of my code reads > > > module implementation (clk_100, resetl, button, segment2, segment1, led, > countednumber); > input clk_100; > input resetl; > input button; > output [6:0] segment2, segment1; // two seven-segment displays > output led; > > output [2:0] countednumber; > > show dice (clk_100, resetl, countednumber, segment1, segment2); // shows > selectednumber as dice eyes > numbergenerator counter (clk_100, resetl, countednumber, button, led); // > count while button is pressed > > endmodule > > > The "resetl" signal was added after I had been working on the code for a > while. And if you wonder, the code implements an electronic dice. > numbergenerator counts on clk_100 as long as I keep button pressed. show > continuously translates the generated number into dice eyes. > > > >Article: 45526
Hi I am synthesising a memory management system using LeonardoSpectrum (level 1 - web edition) and the code is written in VHDL. What I am trying to do is shift data into an array as it is received. Currently the array is 32 bits in length. The problem is that the length of the data that I add to the array varies, and what I find is the shifting (left) concept when dealing with variable bit lengths requires far too many logic elements. As far as the synthesis is concerned, currently the entire piece of code is placed in logic cells. This is too expensive! Is there a way to define the array as memory rather than logic cells or is there another method of combining new and old (variable length) data together besides shifting and then combining within an array? Any assistance would be greatly appreciated. Thanks RyanArticle: 45527
Registering inputs or having the logic fed by the inputs close to those IOBs would help reduce the hold time. The spread between worst setup and worst hold is due to the different propagation times for the input logic. If you can get the inputs registered in the IOBs, you will have no hold times and still very good setups. If you can't afford the "extra" clock cycle, manual placement of the logic can help out. 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: 45528
As Giuseppe's suggestion sat around my brain for a while, I got to like the hybrid approach more and more. In telecom (SDH), often I needed gating for various bytes in the frame overhead. I had several lines in the frame and bytes of interest at the front of each line. If a different line "strobe" was used for the start of each line in the frame (generated from a counter), the strobe could be passed through different SRL16 elements with delays programmed from one to 16 (or 2 to 17 if you include the nice little output register attached to the SRL16 element) allowing multiple strobes coming at precisely the right time based on the row strobe event. Ideally there's two counters in the SDH framing system: a column count and a row count. The column count is a byte-by-byte tracking of the input data with a modulus that's the length of the row; when the column counter resets the row counter increments. The strobe from the row count - when it increments - feeds the strobe chain to give the gating to the correct bytes. No magnitude comparators needed. None.Article: 45529
Triax is a shielded, twisted pair. Quadrax has two shields around the pair. Even coaxial cables leak. Otherwise any coax with the same dielectric would do. There's hundreds of types of RG59 available. The theoretical model of a coaxial transmission line has no external crosstalk - everything balances out. A critical spec for "coax ribbon cables" is the propagation delay match between signals. A differential signal taking two different routes won't switch with the same kind of symmetry. While the twisted pairs won't emit much energy because of the differential nature, they are susceptible to common mode coupling from outside sources. But the LVDS receivers are built to reject the common mode and only look at the differential. Coax reduces crosstalk and emissions. Differential tranceivers reduce the effects of crosstalk and reduce emissions. Differential transceivers guarantee matched propagation delays, coax doesn't. JP Nicholls wrote: > > > > More important, coax cables reject external fields a whole > > > > lot better than twisted pair, > > > > > > How come? Unless the co-ax shielding is ferromagnetic, > > > surely a co-axial pair will present a greater area to any > > > local magnetic fields => induced currents. This area will > > > be hugely reduced with a twisted pair. > > > > It is the symmetry - in a coaxial cable the outer conductor is > > perfectly symmetrically arranged around the inner conductor, so they > > both see exactly the same magnetic field, and the pickup is zero > > over-all. Do the math. > > I agree with this completely for a *single-ended* signal, > but what about *differential* signalling? Your original > reply was: > > > More important, coax cables reject external fields a whole lot better > > than twisted pair, and routing a differential pair of signals along > > physically coupled pair of coax cables will do a better job than > > routing the same signal along a shielded twisted pair. At a much > > higher price .... > > I'm assuming that you mean that the co-axial *pair* is > arranged so that the two polarities of the differential > signal are travelling side-by-side in physically separated, > shielded cables. Maybe I'm missing something, but I can't > see how this presents less loop area to an external field? > > Thanks for you interest and help.Article: 45530
Nope, long delays on the data inputs will increase the set-up time. He has
a long delay on the clock path. Use the DLL to reduce the clock distribution
delay.
John_H wrote:
> Registering inputs or having the logic fed by the inputs close to those
> IOBs would help reduce the hold time. The spread between worst setup and
> worst hold is due to the different propagation times for the input logic.
> If you can get the inputs registered in the IOBs, you will have no hold
> times and still very good setups. If you can't afford the "extra" clock
> cycle, manual placement of the logic can help out.
>
> 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.
> > Anjan
--
--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: 45531Thanks Troy, I'm a lot less confused now, at least when it comes to the pinout. I played with wait's and @'s the other day, and the Constraints Editor had strong opinions on those as well. I'll look more deeply into those tomorrow morning and post again if there are still problems. -- Børge "Troy Schultz" <tschultz@canada.com> wrote in message news:3D401458.9090904@canada.com... > I too was recently a newbie to the Xilinx Webpack software, but found it > to be a fiarly good piece of software. > > The problem you are having with the constraint editor, I believe is due > to the changes you have made to your design not being saved. Make sure > you save any design/code chages before entering the constraint editor. > > Also if you have removed pins from the design/code you will have to > manually edit the constraint file to remove them. Normally one would do > most of thier design and allow the software to do as it pleases, then > lock the design, then use the constraint editor. > > Once you have used the constraint editor, keep in mind that you are > essentially working with a locked design, and may have to manually edit > changes. > > Hope this helps and doesn't confuse things too much. > - Troy > > > Børge Strand wrote: > > Is it just me, or can the WebPack icon "Edit Implementation Constraints > > (Constraints Editor)" be a little touchy? > > > > I'm really a novice when it comes to FPGA programming, so having somewhere > > to point and click is a nice start. But when I add new signals (which I want > > to map to pins) to my source code, they don't appear in the list in the > > Constraints Editor. Initially, in a brand new project, it finds several > > signals and lets me assign pins to them. But as I keep working, making the > > Constraints Editor find, and not least save, my signals gets increasingly > > difficult. > > > > When I add a signal/pin in my source code, and the Constraints Editor fails > > to see it, I rather edit the ucf file. If I hit the Constraints Editor again > > after updating the ucf, the constraints editor refuses to start, stating > > that my newly added signal does not exist. > > > > I'm all ears if you have any suggestion regarding what I should do about the > > Constraints Editor. I'd like to use it if I could only find it trustworthy. > > But the best thing would be to put the constraints into my verilog code. I > > mean, your modules could go with a verilog testbench for simulation and a > > verilog constraints file for implementation. > > > > > > Regards, > > > > Børge > > > > > > The error message and code are inserted below. > > > > ERROR:NgdBuild:397 - Could not find NET 'resetl' in design 'implementation'. > > NET entry is 'NET "resetl" LOC = "D8"; > > ' > > ERROR:Parsers:11 - Encountered unrecognized constraint while parsing. > > ERROR:NgdBuild:19 - Errors found while parsing constraint file > > "implementation.ucf". > > > > > > while the top of my code reads > > > > > > module implementation (clk_100, resetl, button, segment2, segment1, led, > > countednumber); > > input clk_100; > > input resetl; > > input button; > > output [6:0] segment2, segment1; // two seven-segment displays > > output led; > > > > output [2:0] countednumber; > > > > show dice (clk_100, resetl, countednumber, segment1, segment2); // shows > > selectednumber as dice eyes > > numbergenerator counter (clk_100, resetl, countednumber, button, led); // > > count while button is pressed > > > > endmodule > > > > > > The "resetl" signal was added after I had been working on the code for a > > while. And if you wonder, the code implements an electronic dice. > > numbergenerator counts on clk_100 as long as I keep button pressed. show > > continuously translates the generated number into dice eyes. > > > > > > > > > >Article: 45532
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: 45533
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
Article: 45534Dagnabbit, thanks Ray. The hold time issues I was getting in my design were due to logic driven directly by the inputs (as opposed to IOB registers) that was *too* close to the IOBs. If the logic has to be fed live as opposed to by IOB input registers, LOCs can be used to set the logic elements *further* inside the device. Hold times will be reduced, then eliminated as the logic has longer routes. The different input paths have different setup/hold times associated with each. Only the shortest delays need to be adjusted - the longest delays (and tsu values) are already giving you the worst setup numbers but zero hold values. You can strike a balance to get the hold violations delayed enough for zero hold time but not worsen the setup. My apologies for the misinformation. Ray Andraka wrote: > Nope, long delays on the data inputs will increase the set-up time. He has > a long delay on the clock path. Use the DLL to reduce the clock distribution > delay.Article: 45535
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.</i> 2. There is a known problem in 4.2i where RLOC_ORIGIN constraints on single component RPMs are dropped. This problem is described in http://www.support.xilinx.com/techdocs/12192.htm 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 ApplicationsArticle: 45536
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 w=
ith 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 chang=
ing 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 mor=
e stuff
using the MULT_AND
and set/reset on the DFFs.
G=F6ran
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)=
=2E
> 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=3D'1' then
> Y <=3D A + B;
> else
> Y <=3D 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=3D'1' then
> Y <=3D ('0' & A) + ('0' & B);
> else
> Y <=3D ('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 =3D A +(-B) =3D A + ((not B) + 1).
>
> variable tmp: integer;
> variable cin: std_logic;
>
> if op =3D '1' then
> tmp :=3D conv_integer(B);
> cin :=3D '0';
> else
> tmp :=3D conv_integer(not B);
> cin :=3D '1';
> end if;
>
> Y <=3D 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 sl=
ices.
> 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 are=
a)?
> 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 tha=
t
> 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
Article: 45537Hi Børge, The constraints editor only works on synthesised logic so if you break your design It will complain. Ever time you change a file, webpack will recompile the code first. The errors are because you broke your code and not coming from the Constraints editor. Hope this makes sense, Dave "Børge Strand" <borge.strand.remove.if.not.spamming@sintef.no> wrote in message news:1027612806.9313@halvan.trd.sintef.no... > Thanks Troy, > > I'm a lot less confused now, at least when it comes to the pinout. I played > with wait's and @'s the other day, and the Constraints Editor had strong > opinions on those as well. I'll look more deeply into those tomorrow morning > and post again if there are still problems. > > -- > Børge snipArticle: 45538
Winnie Hsu <Winnie.Hsu@xilinx.com> wrote in message news:<3D3F41EB.22A2CDB0@xilinx.com>... > Diab C/C++ compiler is the tool for embedded applications > targeting to the PowerPC inside Virtex-II Pro. After the > compilation, the embedded system dev tool chain can initialize > the program memory or load the program memory with the > executables, then PPC can execute the program. > > It is not a 'synthesis' tool that manipulate C/C++ into the fabric. Is there a plan to build a 'synthesis' tool that transforms algorithms written in C/C++ into FPGA fabric?Article: 45539
http://www.xilinx.com/prs_rls/01118celoxicainvest.html Austin Kaplan wrote: > Winnie Hsu <Winnie.Hsu@xilinx.com> wrote in message news:<3D3F41EB.22A2CDB0@xilinx.com>... > > Diab C/C++ compiler is the tool for embedded applications > > targeting to the PowerPC inside Virtex-II Pro. After the > > compilation, the embedded system dev tool chain can initialize > > the program memory or load the program memory with the > > executables, then PPC can execute the program. > > > > It is not a 'synthesis' tool that manipulate C/C++ into the fabric. > > Is there a plan to build a 'synthesis' tool that transforms algorithms > written in C/C++ into FPGA fabric?Article: 45540
jpnicholls@pwav.com (JP Nicholls) wrote in message news:<d61fddc5.0207250438.1f3837dc@posting.google.com>... > > > > More important, coax cables reject external fields a whole > > > > lot better than twisted pair, > > > > > > How come? Unless the co-ax shielding is ferromagnetic, > > > surely a co-axial pair will present a greater area to any > > > local magnetic fields => induced currents. This area will > > > be hugely reduced with a twisted pair. > > > > It is the symmetry - in a coaxial cable the outer conductor is > > perfectly symmetrically arranged around the inner conductor, so they > > both see exactly the same magnetic field, and the pickup is zero > > over-all. Do the math. > > I agree with this completely for a *single-ended* signal, > but what about *differential* signalling? Your original > reply was: > > > More important, coax cables reject external fields a whole lot better > > than twisted pair, and routing a differential pair of signals along > > physically coupled pair of coax cables will do a better job than > > routing the same signal along a shielded twisted pair. At a much > > higher price .... > > I'm assuming that you mean that the co-axial *pair* is > arranged so that the two polarities of the differential > signal are travelling side-by-side in physically separated, > shielded cables. Maybe I'm missing something, but I can't > see how this presents less loop area to an external field? I cringe to agree that you are right, as far as magnetic field interference goes, but there is a complicating factor. If your pair of coaxial cables are grounded at both ends, the shielding presents a "shorted turn" to the magnetic field threading the loop, which reduces the voltage around the loop to the extent that the circulating current cancels the magnetic field. This gets less and less effective as the loop gets longer and the resistance around the loop increases. I seem to remember that the impedance of free space - that is of a loop aerial - is about 300R, so I imagine that the loop has to get fairly long before this shielding becomes ineffective. In my specific application, we were being pretty paranoid, and our balanced pair of coaxial links were originally specified as semi-rigid coax - RG405 - where the screen is a solid copper tube on solid Teflon/PTFE dielectric. We had them assembled by a specialist firm - Quadrant Connectors in the U.K. - who told us that Alcatel Quickform 86, where the screen is tin-soaked copper braid, is somewhat cheaper (if still pretty expensive) and a lot easier to handle and to solder to the relevant coax connectors. One of the advantages of these cables is that they offer 100% electrostatic screening (as well as very good high frequency properties). Another would be that you could solder pairs of cables together along their full length, shortening up the inductive screening loops to an effective diameter of 2.2mm. We didn't think about this at the time, and certainly didn't solder individual pairs together. One of the nice things about posting here is that every now and again you get to realise what you should have done in the past, which may just mean that you can solve a problem before it conmes up the next time you tackle a similar project. Thanks for getting me to think about the subject in more detail. With any luck Win Hill will chime in with a reference to a paper published in 1953 that analysed the problem properly ... ---- Bill Sloman, NijmegenArticle: 45541
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, PrashantArticle: 45542
--------------4022E2826DCB17C0B0344A87 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Prashant, The number of LUTS and CLBs vs LEs don't map easily, as we also make better use of what we have. Basically, a smaller part would fit the larger design due to architectual efficiencies. Now that I have gone way out of my expertise (Peter is out for a few weeks on vacation), I will state that any of our FAEs or sales reps can fill you in on the architectual reasons why we just make better use of what we have, in effect reducing customer costs even further. Beyond just a simple LUT to LE comparsion, one must also take into account the dual port RAM, SRL16, the DLLs, etc. which all have a good effect on further reducing the amount of logic required. This will further increase the overall efficiency than just the logic alone. Of course, one must not only re-target the design, but in some cases take advantage of the structures that are present in order to realize all of the efficiencies (not to mention running it through the tools with similar effort settings: no fair to compare running their tools for weeks with our tools for once through - or vica versa). Austin 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, > PrashantArticle: 45543
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, 1759
Article: 45544
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, 1759
Article: 45545> ISE 4.2 seems like a big step backwards. What happened? Are others > having troubles with 4.2? I have a Spartan-2 design in VHDL that will crunch just fine under 4.1 but immediatly dies in XST in 4.2 with the infamous "FATAL_ERROR:Xst:Portability/export/Port_main.h:116.1.9.4.1 error message, or as I call it, the "I'm too lame a synthesizer to give you a real error message" error. Also I've noticed that the 4.1 XST gives a lot of warnings that do not get flagged in 4.2, at least in my case - stuff like basic sensitivity list warnings. > I am very disappointed in Xilinx and in ISE 4.2. Are we doing > something wrong, or is a 4.2 a step backwards??? So far I have to say XST is a step backwards in 4.1. -JeffArticle: 45546
Prashant,
Although I haven't played around with APEX20K line (I have some
experience with FLEX10KE. Compared to Spartan-II, it's an unforgiving
chip.), I will guess that APEX20K's LE is less efficient when it comes
to packing unrelated LUTs and FFs compared to Virtex family's CLB.
That's because like what Ray (Ray Andraka) said, LE's 4-input LUT will
be reduced to a 3-input LUT when you want the LE's LUT and FF to be
independent.
If I elaborate further, I guess what I am trying to say is that unless
the 4-input LUT's output is connected to the FF within the same LE, you
cannot use the 4-input LUT and the FF at the same time, however, you can
use the 3-input LUT and the FF at the same time, but that isn't nice.
The reason the LE's 4-input LUT gets reduced to a 3-input LUT is because
"data 3" input of the 4-input LUT is also tied to LE's FF (Check the
APEX20K datasheet for details.).
However, if you look at Virtex datasheet's detailed view of a
Slice (1 CLB = 2 Slices), BX or BY input or 4-input LUT's output can
connect to a FF, and BX or BY input are not tied to the 4-input LUT's F1
through F4 inputs, which means that you have a much better chance of
having an unrelated LUT and FF together within the same Slice.
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?
Going back to the LE's efficiency, I won't be surprised if you
need 20% more LUTs or FFs in APEX20K family than in Virtex family just
to fit the same circuit, even if your application doesn't do much
arithmetic (i.e., Mostly random logic.).
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
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
Article: 45547"Spehro Pefhany" <speff@interlog.com> writes: > Right. I predict this so-called "TMS 1000" will be a miserable failure in > the marketplace with such shoddy design. Monthly unit shipments of the TMS 1000 seems to be 0 at the moment. It remains to be seen whether the numbers will increase over time.Article: 45548
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.
> Anjan
Article: 45549Not only that, when the design hierarchy (Keep Hierarchy) is kept, XST still cannot convert regular Verilog tri-state buffers (i.e., assign My_Pin = My_OE ? 1'bz : My_Output;) buried inside a submodule to IOBUF or OBUFT, unless the design hierarchy is flattened, or IOBUF or OBUFT is explicitly instantiate in the design. However, in some case where a blackbox is used in a design, flattening the hierarchy has resulted in XST messing up the synthesis (I have seen valid FFs getting dropped from the design . . .). Hopefully, ISE 5.1's XST will solve the problem, but my expectation isn't too high since these problems have existed since WebPACK ISE 3.3WP8.0's XST (XST Ver. D.27) as far as I know. Kevin Brace (In general, don't respond to me directly, and respond within the newsgroup.)
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