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
John Adair <g1@enterpoint.co.uk> wrote: > Tristate muxes used to a good method in FPGAs prior to Spartan-3/3E/3A > because the resource existed. The internal tristates don't exist in > Spartan-3 and later so a synthesiser will attempt to convert to a > logic function anyway. It might not always get that right as you > physically can't do the tristate. Because of these uncertainies you > might get a bigger, slower, mux this way. It really doesn't make sense to generate an actual MUX, as that would require a preceding priority encoder. Two that are more obvious are AND/OR logic and OR/AND logic, the former gives zero with no enables, the latter one. (OR/AND uses active low enables. The synthsizer can always add inverters where needed.) Assuming the synthesizer knows about them, weak pull-ups should generate the former, and weak pull-downs the latter. If you do know that the synthesizer will generate one of those, does it make more sense to rewrite the logic using one, or just leave it as is? -- glenArticle: 153501
On 12 Mar, 15:57, vtxsupp...@hotmail.com wrote: > Hi, > Pleased to introduce my new tool, VTM 2012. It is intended to be a > table based edit tool for Verilog/VHDL module's interface definition, > and unify the process of HDL coding and document writing. A demo is athttp://www.veriloghdl.org/demo.html > These tools enable you to build the design's framework, both top down > and bottom up styles. I want to design the HDL in even higher level. I > would like to get some ideas on how people think it before VTM's > completeness. I am now considering to add system verilog interface > feature to it. But I see very few people using system verilog feature > like interface in their RTL designs. Do you think it a valuable > feature? Any comment is welcome. > Thanks How does it compare to the old good and free Perlilog ( http://www.billauer.co.il/perlilog.html )? -- Regards, WZabArticle: 153502
Hello All , I am designing a module that has to run at 350MHz. I am in the architecture phase and would like to know how to figure out the possible frequency of operation of the design before entering the synthesis phase. Normally we have to wait till the synthesis to get an idea about the frequency of operation. I need a rough idea with 10-15% error margin. What if the frequecncy fails to meet the requrement and the difference is very big and cannot be solved in the RTL optimization or syntheis techniques. This amounts to again visiting the High level design to figure out the bottlenecks . I am interested in the techniques to find the rough idea of the frequency of operation in the early phase of the design to meet the frequency of demand if it is high speed design . Secondly how to get a rough idea about the no of flops in the design before entering the synthesis phase. sharing any handout or methodology followed will be highly appreciated. THanks VipsArticle: 153503
Vips <thevipulsinha@gmail.com> writes: > Hello All , > > I am designing a module that has to run at 350MHz. I am in the > architecture phase and would like to know how to figure out the > possible frequency of operation of the design before entering the > synthesis phase. Normally we have to wait till the synthesis to get an > idea about the frequency of operation. I need a rough idea with 10-15% > error margin. What FPGA family are you targetting? Is your application amenable to pipelining? Have you done anything similar before? How much of it is going to be dominated by the LUT timing, how much by the DSP/RAM blocks? If you know what you are doing, and it's not too different a task to previous ones, you might get within 15% without writing any code. If not, I'd be tempted to hire someone that does have that experience to do you a design study. > > What if the frequecncy fails to meet the requrement and the difference > is very big and cannot be solved in the RTL optimization or syntheis > techniques. This amounts to again visiting the High level design to > figure out the bottlenecks . Yes, that's life. Do the work up front if you already know enough, or do enough work to learn enough. Then you'll know. > > I am interested in the techniques to find the rough idea of the > frequency of operation in the early phase of the design to meet the > frequency of demand if it is high speed design . > > Secondly how to get a rough idea about the no of flops in the design > before entering the synthesis phase. Not usually an issue, unless (as someone else said recently) you're Ray Andraka :) I always run out of LUTs first. Again estimations can be done by one skilled in the art, but the accuracy depends on how well you understand what you are going to be implementing. > > sharing any handout or methodology followed will be highly > appreciated. I think the best methodology (unless I'm seriously misreading your/you employers existing capabilities) is to get some help in. (And that's not a pitch for work, I have plenty on already I'm afraid!) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 153504
The record types in VHDL are very useful when designing more
complicated systems. However if you need to store data of record
types to memory or FIFO, it is necessary to convert such data
to the std_logic_vector type.
Similarly, when such data are read from the memory or FIFO,
it is necessary to convert to the original record type.
This problem was often discussed, eg. here:
http://stackoverflow.com/questions/3985694/serialize-vhdl-record
http://objectmix.com/vhdl/190447-converting-records-std_logic_vector.html
Finally I've decided to prepare a Python script which automatically
generates the appropriate VHDL package containing both the
records type declaration and functions to convert between this type and
std_logic_vector.
The input data is a "description file" containing:
1. The record type name in the first non-comment line:
record name_of_my_type
2. A few (at least 1) field declarations, which may have two forms:
name_of_the_field,type,number_of_bits
or
name_of_the_field,type,nr_of_left_bit,nr_of_right_bit
the type may be either "signed" or "unsigned"
3. The end line, consisting of a single "end" word.
The description file may contain also multiple comment lines, containing
the hash "#" character in the first column.
For example if you run:
$ ./rec_to_pkg.py test1.rec
with the following test1.rec:
# This is a test record - packet descriptor
record pkt_desc
# Below are fields definitions
# First two pointers for linked list
# prv - previous
prv,unsigned,6
# nxt - next
nxt,unsigned,6
# Then address to the packet data
addr,unsigned,15,0
# Finally flags
flags,unsigned,9,2
end
You'll get the following VHDL package:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
package pkt_desc_pkg is
type pkt_desc is record
prv : unsigned(5 downto 0);
nxt : unsigned(5 downto 0);
addr : unsigned(15 downto 0);
flags : unsigned(9 downto 2);
end record;
constant pkt_desc_width : integer := 36;
function pkt_desc_to_stlv(
constant din : pkt_desc)
return std_logic_vector;
function stlv_to_pkt_desc(
constant din : std_logic_vector)
return pkt_desc;
end pkt_desc_pkg;
package body pkt_desc_pkg is
function pkt_desc_to_stlv(
constant din : pkt_desc)
return std_logic_vector is
variable res : std_logic_vector(35 downto 0);
begin
res(5 downto 0) := std_logic_vector(din.prv);
res(11 downto 6) := std_logic_vector(din.nxt);
res(27 downto 12) := std_logic_vector(din.addr);
res(35 downto 28) := std_logic_vector(din.flags);
return res;
end pkt_desc_to_stlv;
function stlv_to_pkt_desc(
constant din : std_logic_vector)
return pkt_desc is
variable res : pkt_desc;
begin
res.prv:=unsigned(din(5 downto 0));
res.nxt:=unsigned(din(11 downto 6));
res.addr:=unsigned(din(27 downto 12));
res.flags:=unsigned(din(35 downto 28));
return res;
end stlv_to_pkt_desc;
end pkt_desc_pkg;
Such automatic handling of the record type declaration and of conversion
functions should minimize nember of errors due to mistakes in mapping
of record's fields into the bits of the std_logic_vector.
Please note, that the information about the total number of bits in our
record type is generated as name_of_my_type_width
(pkt_desc_width in the above example).
I hope, that you'll find this script useful.
As it is published as PUBLIC DOMAIN, you are free to modify and use it
in any way you want.
Wojciech M. Zabolotny
wzab@ise.pw.edu.pl
Article: 153505In the previous message I'have forgotten to provide link to the announced script. It has been published in "alt.sources" Usenet group. See http://groups.google.com/group/alt.sources/browse_frm/thread/53ea61208013e9d1 Or look for topic "Script to generate VHDL package for conversion between the record type and std_logic_vector" If you want to unpack the archive from the Google archive, remember to select "show original" option. Otherwise the indendation of the Python source will be damaged. -- Regards, WZabArticle: 153506
On Monday, March 19, 2012 1:57:36 PM UTC-4, Wojciech M. Zabolotny wrote: > The record types in VHDL are very useful when designing more > complicated systems. However if you need to store data of record > types to memory or FIFO, it is necessary to convert such data=20 > to the std_logic_vector type. > Similarly, when such data are read from the memory or FIFO,=20 > it is necessary to convert to the original record type. > This problem was often discussed, eg. here: > http://stackoverflow.com/questions/3985694/serialize-vhdl-record > http://objectmix.com/vhdl/190447-converting-records-std_logic_vector.html >=20 Note that the 'objectmix.com' link that you reference also presents a solut= ion that does not require any other language. Kevin Jennings Additional links for more information: https://www.google.com/webhp?sourceid=3Dnavclient&ie=3DUTF-8#hl=3Den&sclien= t=3Dpsy-ab&q=3Dto_std_logic_vector+from_std_logic_vector+kevin+jennings&oq= =3Dto_std_logic_vector+from_std_logic_vector+kevin+jennings&aq=3Df&aqi=3D&a= ql=3D1&gs_sm=3D3&gs_upl=3D3469l3469l1l3984l2l2l0l0l0l0l156l296l0.2l2l0&gs_l= =3Dhp.3...3469l3469l1l3984l2l2l0l0l0l0l156l296l0j2l2l0.cqn.1.&pbx=3D1&bav= =3Don.2,or.r_gc.r_pw.r_qf.,cf.osb&fp=3D2f01f92557ed5155&biw=3D1290&bih=3D88= 7Article: 153507
On Mar 16, 2:57=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > John Adair <g...@enterpoint.co.uk> wrote: > > Tristate muxes used to a good method in FPGAs prior to Spartan-3/3E/3A > > because the resource existed. The internal tristates don't exist in > > Spartan-3 and later so a synthesiser will attempt to convert to a > > logic function anyway. It might not always get that right as you > > physically can't do the tristate. Because of these uncertainies you > > might get a bigger, slower, mux this way. > > It really doesn't make sense to generate an actual MUX, as that > would require a preceding priority encoder. > > Two that are more obvious are AND/OR logic and OR/AND logic, > the former gives zero with no enables, the latter one. > (OR/AND uses active low enables. The synthsizer can always add > inverters where needed.) > > Assuming the synthesizer knows about them, weak pull-ups should > generate the former, and weak pull-downs the latter. > > If you do know that the synthesizer will generate one of those, does > it make more sense to rewrite the logic using one, or just leave it > as is? > > -- glen I actually is using weak pull-down for my test bench to get right RTL simulation results. I'm not aware that this can also direct Synthesizer's results, I thought the weak pull-down buffers are not recognized by Synthesizers. I'll give it a try to see whether it works, then I don't need to convert all the tri-state buffers to OR- GATE manually. Thanks for the information Best Regards, HaiwenArticle: 153508
On 20 Mar, 02:37, KJ <kkjenni...@sbcglobal.net> wrote: > On Monday, March 19, 2012 1:57:36 PM UTC-4, Wojciech M. Zabolotny wrote: > > The record types in VHDL are very useful when designing more > > complicated systems. However if you need to store data of record > > types to memory or FIFO, it is necessary to convert such data > > to the std_logic_vector type. > > Similarly, when such data are read from the memory or FIFO, > > it is necessary to convert to the original record type. > > This problem was often discussed, eg. here: > >http://stackoverflow.com/questions/3985694/serialize-vhdl-record > >http://objectmix.com/vhdl/190447-converting-records-std_logic_vector.... > > Note that the 'objectmix.com' link that you reference also presents a solution that does not require any other language. > > Kevin Jennings > > Additional links for more information:https://www.google.com/webhp?sourceid=navclient&ie=UTF-8#hl=en&sclien... Yes, I know, but it seems to me, that it requires manual allocation of bit ranges in the std_logic_vector so that record fields do not overlap. If the width of any field is changed, this allocation must be recalculated, which may lead to errors. Have I missed something? Wojtek ZabolotnyArticle: 153509
"Wojciech M. Zabolotny" <wzab@ise.pw.edu.pl> wrote in message news:slrnjmessg.64b.wzab@wzab.nasz.dom... > The record types in VHDL are very useful when designing more > complicated systems. However if you need to store data of record > types to memory or FIFO, it is necessary to convert such data > to the std_logic_vector type. Altera's Quartus2 (10.x+) seems to be able to instanciate arrays of records as memory in basic cases. You may have a problem if you index the different items in the record with different indexes and/or from clock domains, so better be careful. I assume this will be resolved in a future version.Article: 153510
On 20 Mar, 09:16, "Morten Leikvoll" <mleik...@yahoo.nospam> wrote: > "Wojciech M. Zabolotny" <w...@ise.pw.edu.pl> wrote in messagenews:slrnjmessg.64b.wzab@wzab.nasz.dom... > > > The record types in VHDL are very useful when designing more > > complicated systems. However if you need to store data of record > > types to memory or FIFO, it is necessary to convert such data > > to the std_logic_vector type. > > Altera's Quartus2 (10.x+) seems to be able to instanciate arrays of records > as memory in basic cases. You may have a problem if you index the different > items in the record with different indexes and/or from clock domains, so > better be careful. I assume this will be resolved in a future version. Yes, for inferred FIFOs and RAMs it worked both in Quartus and ISE for quite a long time (I don't remember in which version I've used it successfully for the first time). However the problem is if you need to use e.g. more complicated FIFO generated by the CORE Generator, which has input and output of std_logic_vector type.Article: 153511
"wzab" <wzab01@gmail.com> wrote in message news:c160299b-a585-428a-9b73-938e041854c8@9g2000vbq.googlegroups.com... > On 20 Mar, 09:16, "Morten Leikvoll" <mleik...@yahoo.nospam> wrote: >> "Wojciech M. Zabolotny" <w...@ise.pw.edu.pl> wrote in >> messagenews:slrnjmessg.64b.wzab@wzab.nasz.dom... >> >> > The record types in VHDL are very useful when designing more >> > complicated systems. However if you need to store data of record >> > types to memory or FIFO, it is necessary to convert such data >> > to the std_logic_vector type. >> >> Altera's Quartus2 (10.x+) seems to be able to instanciate arrays of >> records >> as memory in basic cases. You may have a problem if you index the >> different >> items in the record with different indexes and/or from clock domains, so >> better be careful. I assume this will be resolved in a future version. > > Yes, for inferred FIFOs and RAMs it worked both in Quartus and ISE for > quite > a long time (I don't remember in which version I've used it > successfully > for the first time). > > However the problem is if you need to use e.g. more complicated FIFO > generated > by the CORE Generator, which has input and output of std_logic_vector > type. I try to stay away from coregen functions as much as I can to make portable code. Unfortunately I'm very often forced to :( But inferring RAM has never bee the problem really. I know some oldtimers that are afraid to, maybe because of the history of old implementation tools, but I've become very confident with it. If I get problems with a long record with multiple domains together with dual port and different access widths on in/out, I prefer splitting the record into many subrecords or subvectors to make it easier for the tool.Article: 153512
On Tuesday, March 20, 2012 3:34:50 AM UTC-4, wzab wrote: > On 20 Mar, 02:37, KJ <kkjenni...@sbcglobal.net> wrote: > > On Monday, March 19, 2012 1:57:36 PM UTC-4, Wojciech M. Zabolotny wrote= : > > > The record types in VHDL are very useful when designing more > > > complicated systems. However if you need to store data of record > > > types to memory or FIFO, it is necessary to convert such data > > > to the std_logic_vector type. > > > Similarly, when such data are read from the memory or FIFO, > > > it is necessary to convert to the original record type. > > > This problem was often discussed, eg. here: > > >http://stackoverflow.com/questions/3985694/serialize-vhdl-record > > >http://objectmix.com/vhdl/190447-converting-records-std_logic_vector..= .. > > > > Note that the 'objectmix.com' link that you reference also presents a s= olution that does not require any other language. > > > > Kevin Jennings > > > > Additional links for more information:https://www.google.com/webhp?sour= ceid=3Dnavclient&ie=3DUTF-8#hl=3Den&sclien... >=20 > Yes, I know, but it seems to me, that it requires manual allocation of > bit ranges in the std_logic_vector so that > record fields do not overlap. If the width of any field is changed, > this allocation must be recalculated, which may lead > to errors. Have I missed something? >=20 Yes, the record type must be updated (and that's the only thing) with the c= orrect bit field positions but this is not really much of a problem for the= following reasons: - One of the primary usages is to map bit fields for a software interface. = Interfaces have specifications that must be adhered to so the typing in of= the bit positions is really just implementation of that part of the specif= ication. Yes, I also know that some like to generate documentation (aka sp= ecification) from the code, but I've yet to meet the software person who is= happy to have a fluid interface. The software design will have a similar = typed in bit position interface definition defined in some header file in t= he language of their choice. Having the hardware design magically change b= it field positions allows the hardware designer to be lazy by not forcing a= specification update or even notification to others that are affected...no= w if you're a one man show doing hardware and software, maybe that's OK, bu= t if that should ever change...well... - The record type definition has the bit field positions all right there, a= nd can be visually inspected pretty easily...subject to error I agree. - When you make a change, you do check that it's working in simulation, cor= rect? Not saying the Python script isn't useful. The tradeoff has to do with add= ing another tool into the design flow that needs to be managed and understo= od by everyone who will use and support the tool over the entire lifetime o= f the design. Kevin JenningsArticle: 153513
The xilinx documentation has got helpful tables in giving information about fmax for various structures such as BRAM, CAM etc. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153514
On 20 Mar, 12:31, KJ <kkjenni...@sbcglobal.net> wrote: > On Tuesday, March 20, 2012 3:34:50 AM UTC-4, wzab wrote: > > On 20 Mar, 02:37, KJ <kkjenni...@sbcglobal.net> wrote: > > > On Monday, March 19, 2012 1:57:36 PM UTC-4, Wojciech M. Zabolotny wro= te: > > > > The record types in VHDL are very useful when designing more > > > > complicated systems. However if you need to store data of record > > > > types to memory or FIFO, it is necessary to convert such data > > > > to the std_logic_vector type. > > > > Similarly, when such data are read from the memory or FIFO, > > > > it is necessary to convert to the original record type. > > > > This problem was often discussed, eg. here: > > > >http://stackoverflow.com/questions/3985694/serialize-vhdl-record > > > >http://objectmix.com/vhdl/190447-converting-records-std_logic_vector= .... > > > > Note that the 'objectmix.com' link that you reference also presents a= solution that does not require any other language. > > > > Kevin Jennings > > > > Additional links for more information:https://www.google.com/webhp?so= urceid=3Dnavclient&ie=3DUTF-8#hl=3Den&sclien... > > > Yes, I know, but it seems to me, that it requires manual allocation of > > bit ranges in the std_logic_vector so that > > record fields do not overlap. If the width of any field is changed, > > this allocation must be recalculated, which may lead > > to errors. Have I missed something? > > Yes, the record type must be updated (and that's the only thing) with the= correct bit field positions but this is not really much of a problem for t= he following reasons: > - One of the primary usages is to map bit fields for a software interface= . =A0Interfaces have specifications that must be adhered to so the typing i= n of the bit positions is really just implementation of that part of the sp= ecification. =A0Yes, I also know that some like to generate documentation (= aka specification) from the code, but I've yet to meet the software person = who is happy to have a fluid interface. =A0The software design will have a = similar typed in bit position interface definition defined in some header f= ile in the language of their choice. =A0Having the hardware design magicall= y change bit field positions allows the hardware designer to be lazy by not= forcing a specification update or even notification to others that are aff= ected...now if you're a one man show doing hardware and software, maybe tha= t's OK, but if that should ever change...well... > - The record type definition has the bit field positions all right there,= and can be visually inspected pretty easily...subject to error I agree. > - When you make a change, you do check that it's working in simulation, c= orrect? > > Not saying the Python script isn't useful. =A0The tradeoff has to do with= adding another tool into the design flow that needs to be managed and unde= rstood by everyone who will use and support the tool over the entire lifeti= me of the design. > > Kevin Jennings Yes, you are definitely right. In case of building hardware/software interface the allocation of bits for record fields should be known for software. However often i use such record<->std_logic_vector conversions internally, inside of the chip, and then this problem does not exist. If I have to connect the record type (after conversion) to the output port, or to the software readable register, I use the similar script to generate the C headers or C++ headers with this information to assure both flexibility and maintainability. My colleague has even built much more complicated tool for automatic mapping of complex structures in FPGA into software readable objects: http://tesla.desy.de/new_pages/TESLA_Reports/2005/pdf_files/tesla2005-22.pd= f Wojtek ZabolotnyArticle: 153515
Hi WZab, I think all the tools for top level integration have the similar object and= outputs. The difference is how to use them. VTC is very different from other tools. A good and quick way to learn VTC is through a quick demo at http://www.ver= iloghdl.org/demos/demo1.htm=20 Users' goal is to instantiate and connect modules. I saw many people dislik= e such a job. I think through this job one can get a clear knowledge of the= whole project and a sense of achievement. VTC is very easy to learn. You c= an even start to use it without learning. At the same time, many powerful f= unction can guide user's operation. One aim of VTC is to cost users' least operation. User can directly get the= correct result because no opportunity to make a mistake. Users need not to= learn additional complicated rules. I hope this answers your question. For detailed comparisons, you can give a= sample and your current way. I will describe how VTC do it. ThanksArticle: 153516
On Mon, 19 Mar 2012 09:41:49 +0000, Martin Thompson wrote: > Vips <thevipulsinha@gmail.com> writes: > >> Hello All , >> >> I am designing a module that has to run at 350MHz. I am in the >> architecture phase and would like to know how to figure out the >> possible frequency of operation of the design before entering the >> synthesis phase. Normally we have to wait till the synthesis to get an >> idea about the frequency of operation. I need a rough idea with 10-15% >> error margin. > > What FPGA family are you targetting? Is your application amenable to > pipelining? Have you done anything similar before? How much of it is > going to be dominated by the LUT timing, how much by the DSP/RAM blocks? > > If you know what you are doing, and it's not too different a task to > previous ones, you might get within 15% without writing any code. If > not, I'd be tempted to hire someone that does have that experience to do > you a design study. > > >> What if the frequecncy fails to meet the requrement and the difference >> is very big and cannot be solved in the RTL optimization or syntheis >> techniques. This amounts to again visiting the High level design to >> figure out the bottlenecks . > > Yes, that's life. Do the work up front if you already know enough, or > do enough work to learn enough. Then you'll know. > > >> I am interested in the techniques to find the rough idea of the >> frequency of operation in the early phase of the design to meet the >> frequency of demand if it is high speed design . >> >> Secondly how to get a rough idea about the no of flops in the design >> before entering the synthesis phase. > > Not usually an issue, unless (as someone else said recently) you're Ray > Andraka :) I always run out of LUTs first. > > Again estimations can be done by one skilled in the art, but the > accuracy depends on how well you understand what you are going to be > implementing. > > >> sharing any handout or methodology followed will be highly appreciated. > > I think the best methodology (unless I'm seriously misreading your/you > employers existing capabilities) is to get some help in. (And that's > not a pitch for work, I have plenty on already I'm afraid!) You can also prototype the parts that you know, from experience, to be bottlenecks -- but without experience, you can't tell the bottlenecks. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.comArticle: 153517
On a PCI Card I got a XC3SD1800A-4FGG676C. While trying to establish a differential output pair on Pins K23,K22, i got the following message: ---------------------------------------------------------------------------- ERROR:Pack:1107 - Pack was unable to combine the symbols listed below into a single DIFFMTB component because the site type selected is not compatible. The root cause of failure is that the IOSTANDARD=LVDS_33 property is only supported in the TOP and BOTTOM IO banks. Further explanation: The component type is determined by the types of logic and the properties and configuration of the logic it contains. In this case an IO component of type DIFFMTB was chosen because the IO contains symbols and/or properties consistent with differential master usage and a IOSTANDARD=LVDS_33 property. Please double check that the types of logic elements and all of their relevant properties and configuration options are compatible with the physical site type of the constraint. ----------------------------------------------------------------------------- The PCI Board Vendor claims in his manual, that these pins are suited for usage as a diff pair. The Xilinx Datasheets do not say anything against this, IMHO. The Xilinx mapping tool seems to have a different opinion:) What am I doing wrong? Would a DIFFMLR be more suited for Banks 1 and 3? Lost Regards Tobias p.s: from UCF File: -------------- NET "dig_io[30]" IOSTANDARD = LVDS_33; NET "dig_io[30]" LOC = K23; NET "dig_io[31]" IOSTANDARD = LVDS_33; NET "dig_io[31]" LOC = K22; from top level file: -------------------- buf_o_pxlclk: obufds port map (i => o_pxl_clk, o=> dig_io(30), ob => dig_io(31) );Article: 153518
On Mar 21, 7:58=A0am, Tobias Kahre <tobias.ka...@epb- dienstleistungen.de> wrote: > On a PCI Card I got a XC3SD1800A-4FGG676C. > While trying to establish a differential output pair on Pins K23,K22, i g= ot the following message: > > -------------------------------------------------------------------------= --=AD- > ERROR:Pack:1107 - Pack was unable to combine the symbols listed below int= o a > =A0 =A0single DIFFMTB component because the site type selected is not com= patible. > =A0 =A0The root cause of failure is that the IOSTANDARD=3DLVDS_33 propert= y is only > =A0 =A0supported in the TOP and BOTTOM IO banks. > > =A0 =A0Further explanation: > =A0 =A0The component type is determined by the types of logic and the pro= perties and > =A0 =A0configuration of the logic it contains. In this case an IO compone= nt of type > =A0 =A0DIFFMTB was chosen because the IO contains symbols and/or properti= es > =A0 =A0consistent with differential master usage and a IOSTANDARD=3DLVDS_= 33 property. > =A0 =A0Please double check that the types of logic elements and all of th= eir > =A0 =A0relevant properties and configuration options are compatible with = the > =A0 =A0physical site type of the constraint. > -------------------------------------------------------------------------= --=AD-- > > The PCI Board Vendor claims in his manual, that these pins are suited for= usage as a diff pair. > The Xilinx Datasheets do not say anything against this, IMHO. > The Xilinx mapping tool seems to have a different opinion:) > > What am I doing wrong? Would a DIFFMLR be more suited for Banks 1 and 3? > > Lost Regards > Tobias > > p.s: > > from UCF File: > -------------- > NET "dig_io[30]" IOSTANDARD =3D LVDS_33; > NET "dig_io[30]" LOC =3D K23; > NET "dig_io[31]" IOSTANDARD =3D LVDS_33; > NET "dig_io[31]" LOC =3D K22; > > from top level file: > -------------------- > buf_o_pxlclk: obufds port map (i =3D> o_pxl_clk, o=3D> dig_io(30), ob =3D= > dig_io(31) ); The Spartan-3A DSP data sheet (DS610) includes the available pin functionality for every pin. Page 78 K23 - Bank 1 - IO_L46P_1 K22 - Bank 1 - IO_L46N_1 While both of these can be differential they are in Bank 1 which is a side bank. Table 12 has this footnote for the LVDS_33 and LVDS_25 IO standards "These true differential output standards are supported only on FPGA banks 0 and 2. Inputs are unrestricted. See the chapter "Using I/O Resources" in UG331." UG331, starting on page 358, describes the differential I/O support and banking rules. If the text is not clear then Table 10-20 explicitly documents that LVDS_25 and LVDS_33 outputs are only available in Banks 0 and 2 (top and bottom). The bottom line is that these two pins can be used for LVDS, but only for a LVDS input. Since you have assigned an output buffer to these pins you are getting a DRC error. Ed McGettigan -- Xilinx Inc.Article: 153519
On Wed, 21 Mar 2012 08:46:01 -0700 (PDT) Ed McGettigan <ed.mcgettigan@xilinx.com> wrote: > On Mar 21, 7:58=A0am, Tobias Kahre <tobias.ka...@epb- > dienstleistungen.de> wrote: > > On a PCI Card I got a XC3SD1800A-4FGG676C. > > While trying to establish a differential output pair on Pins K23,K22, i= got the following message: > > > > -----------------------------------------------------------------------= ----=AD- > > ERROR:Pack:1107 - Pack was unable to combine the symbols listed below i= nto a > > =A0 =A0single DIFFMTB component because the site type selected is not c= ompatible. > > =A0 =A0The root cause of failure is that the IOSTANDARD=3DLVDS_33 prope= rty is only > > =A0 =A0supported in the TOP and BOTTOM IO banks. > > > > =A0 =A0Further explanation: > > =A0 =A0The component type is determined by the types of logic and the p= roperties and > > =A0 =A0configuration of the logic it contains. In this case an IO compo= nent of type > > =A0 =A0DIFFMTB was chosen because the IO contains symbols and/or proper= ties > > =A0 =A0consistent with differential master usage and a IOSTANDARD=3DLVD= S_33 property. > > =A0 =A0Please double check that the types of logic elements and all of = their > > =A0 =A0relevant properties and configuration options are compatible wit= h the > > =A0 =A0physical site type of the constraint. > > -----------------------------------------------------------------------= ----=AD-- > > > > The PCI Board Vendor claims in his manual, that these pins are suited f= or usage as a diff pair. > > The Xilinx Datasheets do not say anything against this, IMHO. > > The Xilinx mapping tool seems to have a different opinion:) > > > > What am I doing wrong? Would a DIFFMLR be more suited for Banks 1 and 3? > > > > Lost Regards > > Tobias > > > > p.s: > > > > from UCF File: > > -------------- > > NET "dig_io[30]" IOSTANDARD =3D LVDS_33; > > NET "dig_io[30]" LOC =3D K23; > > NET "dig_io[31]" IOSTANDARD =3D LVDS_33; > > NET "dig_io[31]" LOC =3D K22; > > > > from top level file: > > -------------------- > > buf_o_pxlclk: obufds port map (i =3D> o_pxl_clk, o=3D> dig_io(30), ob = =3D> dig_io(31) ); >=20 > The Spartan-3A DSP data sheet (DS610) includes the available pin > functionality for every pin. >=20 > Page 78 > K23 - Bank 1 - IO_L46P_1 > K22 - Bank 1 - IO_L46N_1 >=20 > While both of these can be differential they are in Bank 1 which is a > side bank. >=20 > Table 12 has this footnote for the LVDS_33 and LVDS_25 IO standards > "These true differential output standards are supported only on FPGA > banks 0 and 2. Inputs are unrestricted. See the chapter "Using I/O > Resources" in UG331." >=20 > UG331, starting on page 358, describes the differential I/O support > and banking rules. If the text is not clear then Table 10-20 > explicitly documents that LVDS_25 and LVDS_33 outputs are only > available in Banks 0 and 2 (top and bottom). >=20 > The bottom line is that these two pins can be used for LVDS, but only > for a LVDS input. Since you have assigned an output buffer to these > pins you are getting a DRC error. >=20 > Ed McGettigan > -- > Xilinx Inc. Ed, thank you for clarification. The documentation is really comprehensive, so = sometimes it is difficult for me to catch up with every detail. Since the hardware is finished, I will try to use DIFF_SSTL3 now. TobiasArticle: 153520
I'm having a terrible time getting the V6 PCIe core to consistently meet timing, it works occasionally but usually it misses. I've used the suggested constraints that Coregen puts out but that doesn't seem to be sufficient. There is a 500MHz section in the Xilinx core which is the source of the problems. Has anyone been able to get it to place and route reliably? Is there an area constraint for the 500MHz section or some specific flip flop placements that would help?Article: 153521
What makes you think the 500MHz section in the Xilinx core is the problem not else? "General Schvantzkoph" <schvantzkoph@yahoo.com> wrote in message news:9t1p8pFcvgU1@mid.individual.net... > I'm having a terrible time getting the V6 PCIe core to consistently meet > timing, it works occasionally but usually it misses. I've used the > suggested constraints that Coregen puts out but that doesn't seem to be > sufficient. There is a 500MHz section in the Xilinx core which is the > source of the problems. Has anyone been able to get it to place and route > reliably? Is there an area constraint for the 500MHz section or some > specific flip flop placements that would help? --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---Article: 153522
Hello, Does anybody have a very rough estimate of how fast you can run a 32-bit counter in a Spartan 3AN FPGA? Thanks, JonArticle: 153523
I have a S350A VQFP100 on my custom board, with all the pins connected to large pads all around the chip. I have destroyed 3 pins, total. Two pins can't be used as inputs anymore, and the third lost tri-state ability. BTW, the pins are in two VCC banks. True, my soldering tip is not grounded, but the last pin was destroyed a few days ago, and I didn't physically touched the pad it is connected to for at least 3 months. First two pads I did touch a lot with my soldering tip while testing, so I can believe that it was destroyed by ESD. At that time, I have also soldering 10 other pads near those two, but they didn't die. But what about that third pin? It is a part of the data bus (D2), located in top bank, and it hasn't been touched by soldering tip or even the scope for at least 3 months. So, why did it die?Article: 153524
Damn it, I've found the error, the wire is badly soldered.
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