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 would like to design a module which will enable me to input 12-bit > samples and output 16-bit samples. This requirement can be satisfied by concatenation of the 12 bit input bits (MSB) with 4 '0'-bits (LSB). MarcArticle: 51326
Peter Alfke wrote: > > Thanks to all the people that have defended my statement. :-) > Let me make it even clearer: > > If you compare the XC2VP7 against the well-known XC2V1000: > The P7 has 40 rows by 34 columns, the 2V1000 has 40 rows by 32 > columns. > The P7 has 4928 slices, and the 2V1000 has 5120 slices, so the > difference is 4% in favor of 2V1000 > The P7 has 44 BlockRAMs, and the 2V1000 has 40, so the difference is > 10% in favor of P7. > The 2V1000 has slightly more I/O. > That means, the comparison is very close, but the P7 is cheaper than > the 2V1000. > That means the PowerPC and the eight 3 gigabit transceivers are > really FOR FREE ! > > This is the proverbial progress: > smaller geometries due to more advanced processing (130 nm vs 150 nm) > make a smaller die and lower cost. An accountant would agree, and engineer might want to qualify that :) The same die, without the PPC or SerDes test flows could be cheaper. Xilinx's own web info has a good indication of these Test/Yield costs : http://www.xilinx.com/prs_rls/silicon_vir/0302easy_path.htm # Xilinx Virtex-II Pro EasyPath devices #provide production cost savings from 30 percent for low-density # devices up to 80 percent for the largest Virtex-II Pro FPGAs How does EasyPath work ? - they slash the test coverage, to hike the yields. # isolate and test all resources required of a specific design.. # .. creates a set of configuration patterns and test vectors # specific to that design and combines them into a custom test # program to validate the functionality of all required # FPGA resources. # The result is an application specific device that functions and # performs identically to a Virtex-II Pro Is this significant ? - 30% to 80% saving ( their numbers ) Conclusion : I'm sure if you are large enough, you can get Xilinx to skip the SerDes and Pro testing/yields, and negotiate a cheaper price. - jgArticle: 51327
tbiggs wrote: > > "Steve Casselman" <sc@vcc.com> wrote in message news:<OCqT9.900$CZ6.635@newssvr16.news.prodigy.com>... > > It all has to do with volume. If the Pro gets in more designs than the V2 > > then a larger Pro die will cost less than a smaller V2 die. > > Here are the cost issues the way that I see them: > 1. The Virtex II Pro is .13um, the Virtex II is 0.15um so the Virtex > II Pro is a smaller die and will therefore be cheaper, gate-for-gate. > 2. FPGA logic is much easier and faster to test than processor logic. > You can create test patterns to test every gate pretty quickly in an > FPGA. Testing processor logic is more difficult and time consuming. So > testing costs will be a bit higher for the Pro. > 3. Testing a SerDes at 3.125GHZ costs more than testing a generic > LVPECL IO. So, again, testing costs are a bit higher. > > Will the Virtex II Pro be cheaper? Only Xilinx can say. > > Our designs use lots of logic and lots of IO. A small amount of logic > and IO was sacrificed in the Virtex II Pro to make room for the SerDes > and processors. Yes, Peter, we don't have to use the Pro, but the > salesman was really pushing it on us, telling us that it is the future > of the Virtex line. <snip> Then just push-back :) ( see my other post ). Explain to the salesman, that you are an engineer, not an accountant or purchasing officer, and you would like a quote on 0.13u device minus the testing/yield costs of the Processor and SerDes. the rest is politics ... If enough customers do this, voila. -jgArticle: 51328
I am trying to generate three clocks from my 25 MHz clock input. I
want SysClock (25 MHz), SysClockX2 (50 MHz), and SysClockX4 (100 MHz)
in my XC2S200 Spartan-II design. From the data sheet (Functional
Description, page 24) there is an example using two DLL circuits to
generate 2x and 4x clocks, but I also need 1x. Implementing the
example as-is (i.e. no 1x) is no problem, but when I attempt to take
the CLK0 signal from the first DLL and buffer it via a BUFG, I run
into problems during PAR. Specifically, I get errors about the DLLs
and the three BUFGs not being placed (see PAR Errors below).
This is not too surprising, as the data sheet says "If other clock
output is needed, the clock could access a BUFG only if the DLLs are
constrained to exist on opposite edges (Top or Bottom) of the device."
Also, the Solution Record for the first error (1726) says the same
thing (see http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=9469)
The problem is, I can't seem to figure out how to get the constraints
to work! Here is my attempt:
NET "p_sysclock" LOC = "P185"; # GCLk3 input clock
INST "sysclockdll2" LOC=DLL3; # First DLL
INST "sysclockdll4" LOC=DLL1; # Second DLL
INST "sysclockbuffer" LOC=GCLKBUF3; # 1x clock buffer
INST "sysclockx2buffer" LOC=GCLKBUF2; # 2x clock buffer
INST "sysclockx4buffer" LOC=GCLKBUF1; # 4x clock buffer
When I run these, PAR seems to totally ignore these constraints, and I
get the exact same errors!
Help please!
Thanks!
-Bob
---------
PAR Errors
ERROR:Place:1726 - Could not find an automatic placement for the
following
components:
p_sysclock of type GCLK IOB is placed at P185.
clocksgenerator_hsclocksgenerator_sysclockdll2 of type DLL is
unplaced.
clocksgenerator_hsclocksgenerator_sysclockbuffer of type GCLK
BUFFER is
unplaced.
clocksgenerator_hsclocksgenerator_sysclockx2buffer of type GCLK
BUFFER is
unplaced.
clocksgenerator_hsclocksgenerator_sysclockdll4 of type DLL is
unplaced.
clocksgenerator_hsclocksgenerator_sysclockx4buffer of type GCLK
BUFFER is
unplaced.
ERROR:Place:1727 - Xilinx requires using locate constraints to
preplace such
connected GCLK/GCLKIO/DLL components.
Article: 51329In article <18a34598.0212301510.1262dc40@posting.google.com>, TI <anglomont@yahoo.com> wrote: >Hi group, >-is a course like the one at www.naics.ca >enough to qualify an engineer to find work with vlsi, or masters is needed? >-how risky is a ASIC design career anyway ie >what is the chance Berkeley's 'chip in a day' Simulink to silicon aproach >succeeds completely? >(www.mathworks.com/mason/tag/ proxy.html?dataid=1248&fileid=4207) Doubt it... >- Do you think Asian vlsi engineers are going to be dumped completely or >just partly as soon as they become too expensive compared to people in >some other underdeveloped country? >(http://www.eetimes.com/story/OEG20020627S0032) Well, it's happening to US engineers right now. In the global marketplace that (for better or worse) now exists if employers can find cheaper qaulified labor somewhere else they're going to do it. If a wage differential exists and you're on the high-side then it's only a matter of time before your job is outsourced. Think about it, manufacturing jobs were 'outsourced' (exported) from the US starting in the late 80's and into the 90's. Now engineering jobs are being outsourced and with the internet it's much easier to move these jobs overseas than it was to move manufacturing jobs - we're just talking about moving bits over the internet as opposed to moving materials and factories; it's trivial to move engineering jobs to another locale. Since US engineers would have to be making something close to minimum wage in order to compete with their counterparts in India, China or Russia it's not likely that engineering will remain a viable profession going forward in the US since it's quite difficult to live on minimum wage here - and nobody wants to work for minimum wage in a job that takes the kind of training that vlsi engineering does. This is a catastrophic change for US engineers - most of us don't have a fall-back position and it's not likely that we'll be able to migrate to places where one can survive on these lower wages since most of these countries (like India, China, Russia) make it much harder for us to get a work visa than it is for their people coming to work in the US (via H1B visas). Until the relative costs of living equalize between the US and some of these other countries (and that could take decades) the wage differential will be a problem. ...but I hope this is an overly pessimistic analysis... who knows, there could be unforseen, unaccounted-for market forces, new technologies or political changes that keep this scenario from happening. Phil -- "Or perhaps the truth is less interesting than the facts?" Amy Weiss (accusing theregister.co.uk of engaging in 'tabloid journalism') Senior VP, Communications Recording Industry Association of AmericaArticle: 51330
Obviously you can fatten each 12-bit input up with four extra zeros. But I suppose you want to compact the data, do you? That requires a very shallow FIFO-like structure and a lower read clock frequency. What do you want and what do you have? Peter Alfke ========================== jetmarc wrote: > > I would like to design a module which will enable me to input 12-bit > > samples and output 16-bit samples. > > This requirement can be satisfied by concatenation of the 12 bit input > bits (MSB) with 4 '0'-bits (LSB). > > MarcArticle: 51331
Jim, miscommunication again. Easypath is cheaper 1. because of less testing 2. because of higher yield 3. because marketing wants it to be cheaper for tactical reasons. I think #1 is the least relevant. Testing is a significant cost, but not the dominant one. Silicon and packages are usually much higher contributors. At least that is my educated guess... Peter AlfkeArticle: 51332
Peter Alfke wrote: > > Jim, miscommunication again. > > Easypath is cheaper > 1. because of less testing > 2. because of higher yield > 3. because marketing wants it to be cheaper for tactical reasons. Miscommunication ? Wasn't that what I was saying ? Cheaper(@same die) = less testing/higher Yields * Politics [tactical marketing reasons] .. ? -jgArticle: 51333
Peter Alfke wrote > We always distribute the global clock(s) on one or two horizontal "backbones" > across the chip, but we gate off any vertical "rib" or "branch" that is not > used. This is done automatically without any user intervention. It means that > vertically oriented clocked logic draws less power than horizontally oriented > one. And the carry structure always groups counters and accumulators > vertically. :-) This is probably a nomenclature confusion, but if I go into fpga_editor, it looks as if the backbones are vertical, with horizontal distribution spines feeding all the flops in a quarter of a row. I always assumed that it is these horizontal lines which are turned off to minimize power. This is with Virtex/E.Article: 51334
Jim, I was responding to the dangerous and misleading statement: "Explain to the salesman, that you are an engineer, not an accountant or purchasing officer, and you would like a quote on 0.13u device minus the testing/yield costs of the Processor and SerDes." That creates completely false expectations of a drastic cost ( and thus price) reduction. when not testing certain things. Not true! Greetings Peter Alfke Jim Granville wrote: > Peter Alfke wrote: > > > > Jim, miscommunication again. > > > > Easypath is cheaper > > 1. because of less testing > > 2. because of higher yield > > 3. because marketing wants it to be cheaper for tactical reasons. > > Miscommunication ? Wasn't that what I was saying ? > > Cheaper(@same die) = less testing/higher Yields * Politics [tactical > marketing reasons] .. ? > > -jgArticle: 51335
Peter Alfke wrote: > > Jim, I was responding to the dangerous and misleading statement: > > "Explain to the salesman, that you are an engineer, not an accountant > or purchasing officer, and you would like a quote on 0.13u device > minus the testing/yield costs of the Processor and SerDes." > > That creates completely false expectations of a drastic cost ( and > thus price) reduction. when not testing certain things. Not true! It was a tad tongue in cheek (see smiley in OP ), but it was also meant to be read with my other posting stub, which quotes the Xilinx Easypath stats. I do not see the word 'drastic' in what I wrote, and most engineers would appreciate the price could not exceed ( or come close to ) those referenced by Xilinx in EasyPath claims of 30% to 80%. They would also appreciate that any special flows have a negative cost benefit until the volumes get above a certain level. IIRC, easypath had a 6 figure NRE .... To summarise, I think Tom Biggs is correct in his thrust, and Xilinx COULD, given the will, [==customer demand], offer a lower cost 0.13u flow where the PPC core and SerDes are non qualified. -jgArticle: 51336
Hi,
I am experiencing what I suspect are ESD failures in a Spartan2E design.
In particular the failures are shorted inputs (to ground). The inputs are
configured as LVTTL once configured. However, during configuration the
input is pulled up to 3.3v via a 10K resistor. Is this a problem? What do
the inputs look like electrically? (For example are there the traditional
CMOS input protection diodes?)
Article: 51337Rene Tschaggelar wrote: > I really appreciate to have the major vendors here. > Hoping to have now at least one reader in charge : > > As much as like to use the web based support, I am discouraged. > > I do have to log in, giving name adress and so on plus a password. > The next time, I lost the password, then I enter the name = > street = whatever = aaaaa. The only correct entry is my email. > Then I get a mail back : company does not match or alike, after > a day or two. > There are error description forms to be filled out (forgot > which company) but the message is truncated after 160 characters. > > Common, this is not useable at all. > There is not even an email adress as alternative means. > > I don't want yet another entry in a postal mailing list... Some email/web browsers (like mozilla) can remember what you enter into these name/password pages so that the fields are automatically filled next time you go to that page. The other way is to record all your passwords in a file locally.Article: 51338
Alon, The EP1S25 ES devices have a higher power-up current than the production devices. The typical power-up current for the ES device is 2.5 A (on the 1.5-V VCCINT supply), as shown in the Stratix Errata Sheet version 2.2. This value is typical, and individual devices use more or less current during power up. Also it is important to note that charging the decoupling capacitors on the board will consume some amount of current during the power up, so not all of the current coming from the supply is consumed by the Stratix device. We have improved the EP1S25 production devices, which are available now. These devices are tested for a maximum power-up current of 1.2 A on the VCCINT supply. We are now characterizing the entire Stratix family for power-up current and will update the data sheet with power-up specifications for all Stratix devices. Power-up current in general is quite low for the production Stratix devices. In fact, the EP1S80 is over 3x larger than the EP1S25 and we are seeing typical power-up current that is under 1A. We are still working on what the maximum power-up current will be for the EP1S80, but it should be below 2A or so. Many customers have purchased the EP1S25ES devices and we have not heard any examples of customers seeing the current consumption that you have seen. I would like to suggest that you contact me at Altera and we can try to see why your board shows this characteristic. Regards, Greg Steinke gregs@altera.com Rene Tschaggelar <tschaggelar@dplanet.ch> wrote in message news:<3E1DC550.3060907@dplanet.ch>... > Alon Z wrote: > > Hi All > > > > The problem: The Stratix devices are not functioning after power-up. > > Symptom: 15A power-up current in the 1.5V power supply. > > > > Details: > > We just assembeled a board with three EP1S25F1020C6ES. During > > power-up, the Stratix device consume about 15A current for 20ms. It > > causes the power supply to raise its voltage to 2.8V. > > We had the Stratix device for about 2 month in our stock, so I belive > > they are engineering samples (ES suffix). > > The Stratix devices are the only ones that are connected to the 1.5V > > power supply. > > The power comes from external LAB power-supply with 10mm diameter > > cables. > > > > If the power supply is tuned to 1.8V then the stratix devices are > > waking correctly, then we set it to 1.5V. > > > > Did anyone encounter this problem?. Any suggetions ? > > > > > I'm in the process of doing it. > I was told the engineering samples are known for these > high starting currents. I was told the smallest, the S10 takes > 2.5Amps, and assume the bigger one take more. > > ReneArticle: 51339
I will be testing an FPGA design that is intended to drive a PC for initial checkout and later to an embedded computer using parallel port. I selected the EPP protocol as it looks like it can support what I need to do. The FPGA will output 10 bytes of data to the PC each cycle of operation. The data consists of five 14 bit values output in two bytes each. The FPGA will be performing about 40,000 cycles per second. Think of each cycle as a 25 us frame. Data collection (about 4 us), processing (about 7-8 us) occurs for the first 11-12 us of each frame. When the data is ready the parallel port Interrupt line is asserted. The burst rate during the available 13 us data output portion is around 770 Khz. The times have already been verified in the simulations. For the simulation I used an 800 ns byte cycle. The testbench emulates the PC by responding to the Interrupt, invoking the byte cycle timing as expected from the PC by cycling the Data Strobe line (400 ns low then 400 ns high for each byte). The FPGA responds with Waits and presentation of data bytes at the time defined for the EPP port. I used the timing found in web site www.beyondlogic.org/epp/epp.htm The output of the FPGA is configured for TTL levels, slow transitions. I intend to pipe the FPGA directly to the DB connector and through a 3 ft parallel cable to the PC parallel port. In the PC we will DMA the data to memory and accumulate it for several seconds. A display program will access that memory and generate graphs, etc for visual analysis of the performance and results. Does this approach to PC interfaceing sound feasible? Has anyone out there any prior experience they would like to share? Some Do's and Don'ts? Bob Fischer FPGA independent designerArticle: 51340
Mr. Gustad, You can use the "Decrease Input Delay to Input Register" logic option in Quartus II to decrease the delay from the input pin to the DDR input registers. This logic option can be applied to any signal going into the input registers in the IO Element, including when the input registers act as DDR input registers. It is not set as part of the MegaWizard, but is set just like any other assignment. Figure 64 of the Stratix FPGA Family Data Sheet shows that the Input pin to Input register delay is before the two IOE input registers. This option is set during design and is compiled into the programming file. To change this option you would reconfigure the device with a different programming file. However, there is another way that you could consider - Instead of changing the delay of the data pin to the register, you could change the delay of the clock to the register. This has a similar effect of adjusting the TSU/TH window. The Stratix Enhanced PLL has feature called "PLL Reconfiguration" where certain PLL attributes can be modified by system logic, without loading a new programming file. One of these attributes is a programmable delay on the PLL output. So you would have the ability to change this delay without device configuration, which would have much the same effect as changing the data delay. We are now working on a design example which will show the details of how to implement the reconfiguration. Sincerely, Greg Steinke gregs@altera.com Petter Gustad <newsmailcomp4@gustad.com> wrote in message news:<m3r8bpqowv.fsf@scimul.dolphinics.no>... > The Stratix Data Sheet¹ shows in figure 64 (page 114) Stratix IOE in > DDR Input I/O Configuration. Between the Pad (On-Chip Termination) and > the input register there is a box titled "Input Pin to Input Register > Delay". > > I found the following rather terse description in the data sheet "The > Quartus II Compiler can program these delay to automatically minimize > setup time while providing a zero hold time." > > There seem to be no options to set these delays while using the > Quartus II MegaWizard to create a DDR input register. There appears to > be a compile time "De/Increase Input Delay to Input Register logic > option" in Quartus II. However, there is no input to the generated DDR > input register to set the input delay. > > Is there a way to program these delays during run time (i.e. after the > device has been configured)? Is any detailed documentation available? > > TIA > Petter > > ¹) Digital Library CD October 2002 - DS-STXFAMILY-2.1Article: 51341
In article <3E1F2AA1.739F@designtools.co.nz>, Jim Granville <jim.granville@designtools.co.nz> wrote: >How does EasyPath work ? - they slash the test coverage, to hike the >yields. However, the win, BIG win, on easypath is the savings on the test coverage on the rest of the interconnect. You have a gazillion wires, but only a small percentage of the interconnnect points and only a reasonable fraction of wires are used on any given design. >Conclusion : I'm sure if you are large enough, you can get Xilinx >to skip the SerDes and Pro testing/yields, and negotiate a cheaper >price. Except they will point out, quite rightly, that the number of dies in question is fairly low in terms of failures, although they will happily save the tester-time if your easy-path part doesn't use these. That, and the PowerPC can probably make the rest of the testing faster, although I'm not sure if Xilinx does that. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 51342
Hi all, I got trouble with MicroBlaze MDK2.2 with service pack 2 installed. Development tools is Xilinx ISE Foundation 4.2i. when I used MDK 2.2 without service pack 2, I compile a simple MicroBlaze configuration with UART and timer, the timer interrupt work fine. However, after installed MDK service pack 2 to overcome the problem with xmd of ISE 4.2 service pack 3. The same configuration won't work anymore. The timer interrupt won't work as usual anymore. After debuging, I found out that the interrupt controller in MicroBlaze won't accept the Acknowledge write to IAR register, therefore, interrupt status still set and once timer generated interrupt, the interrupt handler just keeps go on and on. Is there anyone having the same problem before and how to fix it? Will it help if i upgrade to EDK version of MicroBlaze? Thanks Duy K DoArticle: 51343
I only wish Xilinx could have made an ARM deal too. I know, I know, next person will want MIPS and so on. I am pretty sure too that embedded PPC cores are a low priority for most FPGA guys right now but the path to PPC leads to certain markets (higher performance, high value). The path to ARM leads to lower cost and smaller designs I hazard & I bet much larger consumer markets as well as perhaps ASIC conversions. Perhaps Spartan.. pro whatever could have ARM offering instead. If I were a gadget guy counting all the embedded cpus in my toys I'm sure I would find lots of ARMs and few PPCs (although my 3com cable box has one). My last project was needlessly more complex by an order of magnitude because the ARM was external and way too slow. If we had known that Xilinx was heading to PPC and Altera was with ARM back when we started the design many years ago, I probably would have gone the A route for that reason alone but then we also needed them multipliers too. Perhaps a mixed X+A solution? I can certainly understand the IBM technology partnerships though that Xilinx & AMD are following but when you are committed to a cpu architecture and you get something else for free in your lap, doesn't mean we can switch. Enuf of wishingArticle: 51344
ptkwt@shell1.aracnet.com (Phil Tomson) wrote in message news:<avne1q01um3@enews1.newsguy.com>... > In article <18a34598.0212301510.1262dc40@posting.google.com>, > TI <anglomont@yahoo.com> wrote: > >Hi group, > >-is a course like the one at www.naics.ca > >enough to qualify an engineer to find work with vlsi, or masters is needed? > >-how risky is a ASIC design career anyway ie > >what is the chance Berkeley's 'chip in a day' Simulink to silicon aproach > >succeeds completely? > >(www.mathworks.com/mason/tag/ proxy.html?dataid=1248&fileid=4207) > > Doubt it... > > >- Do you think Asian vlsi engineers are going to be dumped completely or > >just partly as soon as they become too expensive compared to people in > >some other underdeveloped country? > >(http://www.eetimes.com/story/OEG20020627S0032) > > Well, it's happening to US engineers right now. In the global marketplace > that (for better or worse) now exists if employers can find cheaper > qaulified labor somewhere else they're going to do it. If a wage > differential exists and you're on the high-side then it's only a matter of > time before your job is outsourced. Think about it, manufacturing jobs > were 'outsourced' (exported) from the US starting in the late 80's and > into the 90's. Now engineering jobs are being outsourced and with the > internet it's much easier to move these jobs overseas than it was to move > manufacturing jobs - we're just talking about moving bits over the > internet as opposed to moving materials and factories; it's trivial to > move engineering jobs to another locale. > > Since US engineers would have to be making something close to minimum wage > in order to compete with their counterparts in India, China or Russia it's > not likely that engineering will remain a viable profession going forward > in the US since it's quite difficult to live on minimum wage here - and > nobody wants to work for minimum wage in a job that takes the kind of > training that vlsi engineering does. > This is a catastrophic change for US engineers - most of us don't have a > fall-back position and it's not likely that we'll be able to migrate to > places where one can survive on these lower wages since most of these > countries (like India, China, Russia) make it much harder for us to get a > work visa than it is for their people coming to work in the US (via H1B > visas). Until the relative costs of living equalize between the US and some of > these other countries (and that could take decades) the wage differential > will be a problem. > > ...but I hope this is an overly pessimistic analysis... who knows, there > could be unforseen, unaccounted-for market forces, new technologies or > political changes that keep this scenario from happening. > > Phil I would have to agree with this assesment atleast right now. From where I am sitting, union blue collar jobs that can't be exported like say painters, plumbers, toll collectors, auto mechanics, seem to be able to easily make maybe half as much as veteran EEs. The pressure on EEs though is getting rediculous, more & more education required for jobs in order to stay only a little further ahead than many tradesmen. However, the HW & SW jobs that seem to have been exported to India & China so far seem to be at the bottom end of the skill spectrum and at the end of the day as long as the US is the leading consumer of technology, I thinks the better jobs will remain here. And English language & culture remains a huge barrier to these countries too esp China/Russia. In the end, most of us do it because we are interested in it, not for the huge $, if you aren't driven by 1s & 0s or whatever, I'd look elsewhere. my 2cArticle: 51345
> I used the USB1.1 core in a project last fall. We only used 2 bulk endpoints > so I can't say we tried it out thoroughly. I packaged it as an OPB peripheral > for a Microblaze system, and as such it used about 10% of a XCV800 chip. > Interesting, could you tell a bit more about your application...the type of transceiver, how the model was connected with actual hardware, etc... Yours, FBArticle: 51346
On 10 Jan 2003 13:25:46 -0800, rsg@payload.com (Robert S. Grimes) wrote:
>I am trying to generate three clocks from my 25 MHz clock input. I
>want SysClock (25 MHz), SysClockX2 (50 MHz), and SysClockX4 (100 MHz)
>in my XC2S200 Spartan-II design.
>The problem is, I can't seem to figure out how to get the constraints
>to work! Here is my attempt:
>
> NET "p_sysclock" LOC = "P185"; # GCLk3 input clock
> INST "sysclockdll2" LOC=DLL3; # First DLL
>When I run these, PAR seems to totally ignore these constraints, and I
>get the exact same errors!
>
>Help please!
The error messages are a pretty good guide to what's wrong.
>PAR Errors
> p_sysclock of type GCLK IOB is placed at P185.
This constraint worked.
> clocksgenerator_hsclocksgenerator_sysclockdll2 of type DLL is
>unplaced.
This constraint won't work because the name on the constraint
("sysclockdll2") does not match the instance name
("clocksgenerator_hsclocksgenerator_sysclockdll2")
And so on.
Edit the constraints file to match the actual instance names.
(Be aware that if you change the design hierarchy or the synthesis
settings, the instance names subsequently generated might change again)
- Brian
Article: 51347> I assume Frederic is using the USB 1.1 core. Yes > > Several issues here: > > 1) The mode pin on the PDIUSBP11A applies to the input to the > transceiver only. The receive side does not change it's > behavior regardless of the mode pin setting. > > 2) The USB 1.1 PHY I provide, allows you to select the mode > as well. Regardless of the mode setting on the "Trenz" board, > you can change the behavior of the RTL by assigning a 1 or 0 > to the "phy_tx_mode" input of the phy. I imitate the behavior > of the mode pin on the PDIUSBP11A with the "phy_tx_mode" input. > You should set the "phy_tx_mode" to the same value as the > mode input on the PDIUSBP11A. > > 3) On the receive side you need at least the "vp" and "vm" > signals, you should be able to use "vp" as the "rcv" signal > as well. > > Hope this helps ! > > Cheers, > rudi Thank you for this information. I will use it to implement USB on my Trenz board and make it available as soon as it works. This might lead me to ask more questions, sorry to annoy you. I read most of the OPENCORE mailing list but some points are not yet 100% clear in my mind as I am just a newbie. Yours, FB PS: happy new year to all FPGA afficionados in this newsgroup!Article: 51348
Hi, I want a 16mhz clock synchronous to Hsync of the video.I want my 16mhz clock should lock on the rising edge of the Hsync. I want a pixel clock for Xilinx Spartan 2 Fpga for Video frame storage Application. I am using oscillator for generating the 16mhz Clock but my video out is not stable it have some color problem on the top of the frame manse on the first 100 lines of the video and it vary on changing of source, first I thought it is a clock stability problem so that I changed the oscillator to 5ppm but the problem is still there so I want a clock synchronous to video Hsync. Can u help me, How can I get the clock synchronous to the video because it is affecting the performance of video. If u have some idea how we can generate in Fpga so pl'z help me out.I Need your urgent Help. Thanks For any suggestion. Regards Arvind.Article: 51349
Has anyone used the SerDes on the VirtexIIP, if so have they been reliable? An on board SerDes make's life a lot simpler if it works but it's also something that can be very hard to get right, so I'm interested in hearing if anyone has used it and if it works well.
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