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
Emanuel, > Anybody out here know about a available PHY for a 2.0 version USB ? being a little bit pragmatic (and looking for something slightly different than what you really want) you may think about the following devices: *** UTMI transceivers *** Kawasaki KLK5KUSB200: probably shipping (www.klsi.com) Cypress EZ-USB-TX2: announced *** with built-in protocol engine *** NetChip 2290: shipping Cypress EZ-USB-SX2: "close to shipping" *** with protocol engine and processor *** Cypress EZ-USB-FX2: shipping Best regards Felix _____ Dipl.-Ing. Felix Bertram Trenz Electronic Duenner Kirchweg 77 D - 32257 Buende Tel.: +49 (0) 5223 4939755 Fax.: +49 (0) 5223 48945 Mailto:f.bertram@trenz-electronic.de http://www.trenz-electronic.deArticle: 42751
>Then on top of it all, while I am trying to expedite the delivery of a >few engineering samples of the XC2S150E in the industrial temp range, I >am told that "BTW, ya know those commercial parts that the distributor >quoted you 6 week lead time? You won't be getting those any time soon >either". In fact I received an email from Xilinx support yesterday >saying that they really haven't even made up their minds yet about >delivery schedules and won't until the end of May!!! Not directed at rickman, but his rant reminded me of an interesting lesson I learned many years ago. New job. I was working on a network board. The group had a person in charge of the lab and his job included getting parts for prototype boards like the one I was designing. This was back when 4K FIFOs were a big deal and FIFOs were not yet commodity parts with standard pinouts. I had a nice stack of data books. They had various small FIFOs, many of them marked Advanced or Preliminary (or perhaps wishful thinking). I wasn't clued into this problem yet so I designed around whatever seemed best at the time. As my design was getting more real, I gave Steve a rough cut at a parts list. Soon he reported that some of the FIFOs I'd picked didn't really exist. No major problem. I flipped through the books and found another one. That one didn't exist either. After a couple iterations, Steve came by with a couple of parts in his hand. Samples. This one really did exist. End of problem. Ever since that day, "Can you get samples?" was our code word for "Does it really exist?" If Steve could get samples, I was happy using it in a design and he was happy too, knowing that he wouldn't get stuck trying to locate an impossible part while everybody was breathing down his neck. "Samples in hand" has been my rule of thumb ever since. Several times I have passed it on to new people. Of course, it sometimes doesn't work when you are using specialized parts, like FPGAs and CPUs or big IO chips. But even then it's a good flag that you might have problems - an issue to put high on your potential risk list. I haven't used bleeding edge Xilinx parts in a long time. They used to be pretty good about publishing a what/when availibility chart in XCell. I'd be suspicious if my plans didn't mesh with that chart, especially if I didn't have samples in hand. Obviously, if you have a good relationship with a vendor or distributor you can sensibly stick your neck out farther. But it takes a while to establish that trust. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 42752
In article <253573e8.0205011258.4a2a8d9c@posting.google.com>, Hassan
Mourad <Hassan_Mourad@lycos.com> writes
>Alan Fitch <alan.fitch@doulos.com> wrote in message news:<h$Zd6gBPA7z8YBum@doulo
>s.co.uk>...
>
>> The simplest way is to implement a reset pin. Your code above almost
>> looks like it is using "load" as a reset.
>>
>> Generally, if you use an asynchronous reset, you should write a process
>> in the style
>>
>> process(clk, reset)
>> begin
>> if reset = '1' then
>>
>> -- reset stuff, e.g. z := 63
>>
>> elsif rising_edge(clk) then
>>
>> -- synchronous actions
>>
>> end if;
>>
>> end process;
>>
>> You should only have one clock edge per process.
>>
>> Also I would declare integers constrained, otherwise you are relying on
>> the synthesis tool to remove unused bits. You can do this like this
>>
>> variable z : integer range 0 to 63; -- unsigned 6 bit
>> variable z2 : integer -32 to 31; -- signed 6 bit
>>
>> Think hardware!
>>
>> regards
>>
>> Alan
>>
>>
>
>I still have the same error , is their any constrain that i must know
>about the range of an array ...
>
>i don't know what's wrong
>
>i've tried the tips that Mr. Alan gave , but nothing new
>
>sincerely
>Hassan
Can you post the error please,
Alan
--
Alan Fitch
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223 Email: alan.fitch@doulos.com
Fax: +44 1425 471573 Web: http://www.doulos.com
**********************************
** Developing design know-how **
**********************************
This e-mail and any attachments are confidential and Doulos Ltd. reserves
all rights of privilege in respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from your system, any use, disclosure, or copying of this document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 42753Hello all, I've been trying to make my own Xilinx parallel cable III using the available schematics. My board is double sided, with a male parallel connector so I can use any parallel cable. The differences between my PCB and the original xilinx one are: (1) D6, Busy and PE are connected on the board, not at the computer end of the cable. (2) The tristate buffer is 74HC125A (3) The diode are 1N4002, not 1N5817. I've tried two different board layouts, both of which work sometimes, depending on which direction the wind is blowing. I've tried both linear and switch mode power supplies. If anyone else has successfully implemented this design I would appreciate some pointers in the right direction. Thanks for your help. Mark.Article: 42755
Hi, finally someone who has a quite similar problem with JTAG. :) I see you try to configure a fpga with a self-build harware and your own device driver. Thats nearly the same i do. And my attempts behave strange too. Apart from the fpga (i use a 800th virtex) and the cable (lately we bought a PC IV - which is able to simulate the same behaviour as the PC III), i use W2k too...basically hardly any difference. I suppose either you made a mistake at your own cable or you forgot to force a driver pin(e.g. pin 5). What about sharing our knowledge and cut the problems in half ? cheers, Jens ---------------------------------------------------------------------------- ----------------------------------------- Jens Frauenschlaeger, <conny@informatik.uni-leipzig.de> University of Leipzig GermanyArticle: 42756
Hello,
Does anyone know how to make nios-elf-gcc to pass parameters
in a specific global register to an exception handler?
I intend to implement the user side of system calls though
#define syscall(p) ({ int _p=(p); asm("trap 5" :: "###" (_p));})
however, I don't know what to write to the '###' field.
Ideas, anyone?
Article: 42757Hi Mark, In opposite to you i turned down the idea of making my own parallel cable III. (i supposed such a influence by the blowing wind :) I'm more interested in the connection between your computer and your board. did you attempt to used the JTAG? did you wrote your own device driver? My thesis should work should work exactly this way. The JTAG interface should be used, furthermore the parallel cable IV(which is compatible to the PC III) should(i like this word...) be used. Well i wrote the device driver according the circut description of the xilinx PC III assuming that PC IV use the same pins, but... but some pins behaves very strange.(maybe influenced by the color of my shoes :) so, what about talking about the cable to halve the problems with the cable? cheers, Jens ---------------------------------------------------------------------------- Jens Frauenschlaeger, <conny@informatik.uni-leipzig.de> University of Leipzig GermanyArticle: 42758
quick note : the samsung DDR k4d263238m supports full page (used in the Xbox console)Article: 42759
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:<aaqifp$lmf$1@newsreader.mailgate.org>... > I am just wondering, why can't you use XC2S150 instead of XC2S150E? > Is it possible to replace the 1.8V voltage regulator with a 2.5V one for > XC2S150? You could just use a 1N4001 diode in series with the 3.3V supply to get ~2.5V. My regulator circuit works like that, except it's using transistors and zeners to do it. Another way would be to use a more available commercial temp chip, and test 10 boards at a time in an environment chamber.Article: 42760
Peter Alfke <peter.alfke@xilinx.com> wrote: : Changes from Virtex to Virtex-E : Virtex-E is a minor change, mainly a shrink for higher speed and cost reduction. : The basic architecture is identical to Virtex, but the family now extends to : larger sizes. You don't mention the additional Block RAMs - not a 'minor' change as far as my applications are concerned ! Richard. http://www.rtrussell.co.uk/Article: 42761
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote: > One problem I had a while ago with a Spartan-II datasheet was it didn't > say that Spartan-II IOB tri-state buffers are active low or high. You should have read the libraries guide - it's the data sheet for the primitives in the library. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 42762
Russell wrote: > > Hi, > > I can't get my spartan2 thing to program. Using impact in win2k, > i can get toggles on pin 4 (TMS_IN) of the pc parallel port, but > no other pins toggle (not even pin 3, CLK). I'm using a copy of > a parallel-III jtag dongle. Could it be anything to do with win2k? > I'm using impact in webpack-4.2. > Hi, I also use impact of webpack-4.2 to program a xilinx chip with JTAG. It works fine under win2k. So I suggest your problem would be a hardware bug. Good luck! WernerArticle: 42763
Bob, The emperor never really had clothes, did he? We never offered a silicon differential driver until Virtex II. The LVPECL is a clever use of two single ended drivers, with three external resistors, two series 100 ohm, and one parallel 187 ohm. Looks like, smells like, and is two single ended drivers. Just that simple. If you want to point out how the two single ended drivers are not a perfectly balanced, low bounce differential driver, please do so without implying that someone here in IC design was doing a lousy job. Other than that, sounds like we are in "violent agreement." Austin Bob Perlman wrote: > Austin - > > I give, I give! You've managed to convince me that Xilinx has > designed a differential transmitter that has poor delay matching, lots > of shoot-through current, high I/O capacitance, and requires three > external resistors at the driver end. > > Nevertheless, I'm sure it's a wonderful driver. > > Bob Perlman > ----- > Cambrian Design Works > http://www.cambriandesign.com > > On Wed, 01 May 2002 12:54:42 -0700, Austin Lesea > <austin.lesea@xilinx.com> wrote: > > > http://www.support.xilinx.com/xapp/xapp133.pdf > > > >See page 32 of the pdf file. > > > >Austin > > > >Bob Perlman wrote: > > > >> Austin - > >> > >> On Wed, 01 May 2002 11:07:53 -0700, Austin Lesea > >> <austin.lesea@xilinx.com> wrote: > >> > >> >Bob, > >> > > >> >Because the LVPECL uses a resitor network to set the levels (r's in series, r's in > >> >parallel). > >> > >> What resistor networks? The Spartan IIE data sheet says that you > >> connect 100 ohms across the rails. Where are the other resistors? > >> > >> Bob Perlman > >> ----- > >> Cambrian Design Works > >> http://www.cambriandesign.com > >> > >> >Also, each IO has the capacitive load of the pin (~ 10 pF) so each IO must charge, and > >> >discharge that capacitance. Charging lowers Vcco (Vcco bounce) and discharging raises > >> >ground (ground bounce). They don't cancel either. > >> > >> >Austin > >> > > >> >Bob Perlman wrote: > >> > > >> >> Austin - > >> >> > >> >> I think we're going in circles here. I mentioned in my first post > >> >> that the cancellation wouldn't be perfect, but that there would be > >> >> some, and that I'd expect it to be significant. > >> >> > >> >> I can agree with your results if: > >> >> > >> >> (a) the true and complement transitions are significantly skewed (bad > >> >> news for the receiver) > >> >> > >> >> (b) crossover current is a significant fraction of the current being > >> >> sourced or sunk by the driver through the I/O pin, and lasts for a > >> >> significant fraction of the rise/falltime. ( I thought that this > >> >> wasn't the case for modern driver designs. Can you give more > >> >> information on duration/amplitude?) > >> >> > >> >> (c) both. > >> >> > >> >> Can you clarify something? You've said that: > >> >> - driver impedance is 7 ohms > >> >> - drivers switch from rail to rail > >> >> > >> >> How do 7-ohm rail-to-rail drivers connected to 3.3V produce 0.85V > >> >> across a 100 ohm load? > >> >> > >> >> Bob Perlman > >> >> ----- > >> >> Cambrian Design Works > >> >> http://www.cambriandesign.com > >> >> > >> >> On Wed, 01 May 2002 07:55:38 -0700, Austin Lesea > >> >> <austin.lesea@xilinx.com> wrote: > >> >> > >> >> >Bob, > >> >> > > >> >> >Simple. The outputs pull all the way to Vcc, and to ground. The switches are not > >> >> >current sources at all, but on and off switches with ~ 7 ohms on resistance. The > >> >> >current is going to flow through the IO pin, through to the ground connections, and > >> >> >the Vcco connections. Just because one is going up when the other is going down > >> >> >doesn't mean they will cancel: the delay from the pad to the package pin (25 ps to > >> >> >125 ps), and to the external resistors is slightly different for each. The loading > >> >> >is slightly different on each as a result. As well, there is a crossover current in > >> >> >a CMOS output driver that flows from Vcco to ground when switching hi, or low, and > >> >> >that is unaffected by this arrangement. > >> >> > > >> >> >So, the lab explains exactly what we expect to happen. > >> >> > > >> >> >I agree that mysteries are a bad thing, and we always drill down until we explain a > >> >> >result completely. > >> >> > > >> >> >Austin > >> >> > > >> >> > > >> >> >Bob Perlman wrote: > >> >> > > >> >> >> Austin - > >> >> >> > >> >> >> I know they're conventional single-ended I/Os; I thought I made that > >> >> >> clear in my analysis (I assumed that the drivers both source and sink > >> >> >> current; real PECL drivers only source current). I'm not sure why > >> >> >> you mentioned LVDS drivers, but they also source and sink. > >> >> >> > >> >> >> If you're not seeing lower ground bounce for Spartan IIE > >> >> >> differerential LVPECL in the lab, it would be useful to figure out > >> >> >> why. If you're not seeing lower ground bounce, I have to wonder if > >> >> >> the true and complementary transitions are simultaneous or > >> >> >> near-simultaneous. If they're not, that could spell big trouble for > >> >> >> the receiver. > >> >> >> > >> >> >> When lab results are counter-intuitive, it pays to find out why. > >> >> >> > >> >> >> Bob Perlman > >> >> >> ----- > >> >> >> Cambrian Design Works > >> >> >> http://www.cambriandesign.com > >> >> >> > >> >> >> On Tue, 30 Apr 2002 14:23:09 -0700, Austin Lesea > >> >> >> <austin.lesea@xilinx.com> wrote: > >> >> >> > >> >> >> >Bob, > >> >> >> > > >> >> >> >These are still plain old single ended IOs, and as measured in the lab, there is > >> >> >> >virtually no difference in ground bounce from a regular single ended IO. > >> >> >> > > >> >> >> >LVDS in Virtex II and Virtex II Pro are current sink and source differential > >> >> >> >drivers, and there is actually a large benefit from such drivers. > >> >> >> > > >> >> >> >Austin > >> >> >> > > >> >> >> >Bob Perlman wrote: > >> >> >> > > >> >> >> >> Austin - > >> >> >> >> > >> >> >> >> On Tue, 30 Apr 2002 10:01:09 -0700, Austin Lesea > >> >> >> >> <austin.lesea@xilinx.com> wrote: > >> >> >> >> > >> >> >> >> >Bob, > >> >> >> >> > > >> >> >> >> >Spartan 2 uses external resistor networks to get the LVPECL levels, so there > >> >> >> >> >is no benefit from differential switching as regards to ground bounce. Each > >> >> >> >> >single ended IO is already switching rail to rail, and driving hard. Thus > >> >> >> >> >even though some of the current flows out comes back in on the other pin, a > >> >> >> >> >lot of current is flowing through power and ground. > >> >> >> >> > > >> >> >> >> >Austin > >> >> >> >> > >> >> >> >> The original poster wanted to use Spartan IIE which, if I'm reading > >> >> >> >> the data sheet correctly, supports LVPECL differential outputs > >> >> >> >> terminated with 100 ohms across the two signals. > >> >> >> >> > >> >> >> >> The VOH range is 1.92-2.28V, or ~2.1V typical; the VOL range is > >> >> >> >> 1.06-1.43V, or~ 1.25V typical. This means that the current through > >> >> >> >> the terminating resistor is approximately (2.1V-1.25V)/100 = 8.5mA. > >> >> >> >> > >> >> >> >> When the differential signal switches, one driver switches from source > >> >> >> >> to sink, while the other switches from sink to source. On the ground > >> >> >> >> side, one driver slews from sinking 8.5 mA to sinking nothing, while > >> >> >> >> the other slews from sinking nothing to sinking 8.5mA. Similar things > >> >> >> >> happen on the VCC side, except that current is being sourced rather > >> >> >> >> than sunk. > >> >> >> >> > >> >> >> >> Beyond a certain point, the strength of the drivers is moot; the > >> >> >> >> current into or out of the I/O pin will be limited by the transmission > >> >> >> >> line impedance. If we think of the differential lines as two 50-ohm > >> >> >> >> single-ended lines, the current needed to send a 0.85V delta V down > >> >> >> >> each line is 17mA, which is exactly the delta you get when you stop > >> >> >> >> sourcing 8.5mA and start sinking it, or vice versa. > >> >> >> >> > >> >> >> >> The balance isn't perfect, but the net di/dt on either the VCC or > >> >> >> >> ground paths should be considerably less than for single-ended > >> >> >> >> signals. > >> >> >> >> > >> >> >> >> Bob Perlman > >> >> >> >> ----- > >> >> >> >> Cambrian Design Works > >> >> >> >> http://www.cambriandesign.com > >> >> >> >> > >> >> >> >> > > >> >> >> >> >Bob Perlman wrote: > >> >> >> >> > > >> >> >> >> >> Hi - > >> >> >> >> >> > >> >> >> >> >> On Tue, 30 Apr 2002 11:34:47 -0400, Theron Hicks > >> >> >> >> >> <hicksthe@egr.msu.edu> wrote: > >> >> >> >> >> > >> >> >> >> >> >Hi, > >> >> >> >> >> > I am seriously considering using a spartan2e to serve as a clock > >> >> >> >> >> >distribution generator for a lvpecl clock system. This clock system > >> >> >> >> >> >will be driving a total of 17 differential clocks. When I price the > >> >> >> >> >> >LVPECL chips the spartan2e looks very competetive. Also, it would give > >> >> >> >> >> >me the clock DLL to clean up my system clock. The question is that I > >> >> >> >> >> >have a total of 34 output lines that should be switching at the same > >> >> >> >> >> >time. The spec says 12 power and ground pairs in the chip and 3 > >> >> >> >> >> >simulatneous outputs per pair. Thus a total of 36 outputs. (one spare > >> >> >> >> >> >pair for me.) How do I split these up over the 12 power/ground pairs? > >> >> >> >> >> >I count 16 grounds and 8 VCC0 on the tq144 package (XC2S50E). Where do > >> >> >> >> >> >I get 12 power/ground pairs from these 24 pins? > >> >> >> >> >> > >> >> >> >> >> If you're using differential outputs, the power and ground di/dt > >> >> >> >> >> should be significantly less than what you'd see for single-ended > >> >> >> >> >> signals. Assuming that the true and complementary transitions occur > >> >> >> >> >> in unison, one driver should be increasing its ground or VCC current > >> >> >> >> >> as the other driver's current is decreasing. The match isn't perfect, > >> >> >> >> >> but it should be pretty good. > >> >> >> >> >> > >> >> >> >> >> Ask Xilinx for diff pair power/ground guidelines; they should be less > >> >> >> >> >> stringent than the guidelines for single-ended signals. > >> >> >> >> >> > >> >> >> >> >> Bob Perlman > >> >> >> >> >> ----- > >> >> >> >> >> Cambrian Design Works > >> >> >> >> >> http://www.cambriandesign.com > >> >> >> >> >>Article: 42764
Hal, I was burned badly once when I got samples in 1975, and then the company that supplied them (started with an "F") decided to discontinue the parts. It all comes down to track record. And trust. Not without reason do people ask if there are samples, or if there is yield, or if the process is reliable. Many things can, and do, go wrong. If it was that easy, there would be a dozen FPGA vendors, and there are not. As a customer, I would advise you work with the vendor(s), develop lines of communications at different levels (eg FAE, sales, Manager to Manager, VP to VP). That way you can find out what you want to know quickly, and with confidence. For our smaller customers, there are people like Peter and myself, who are always willing and able to help out, and get back with accurate and useful information. He and I remember where Xilinx' first customers came from, and we recognize the strength of innovation in all of those thousands of small start-ups. Some of them (like Cisco) were so small that at a conference I once helped organize (Systems Design and Networks Conference, Santa Clara 1988), some people laughed at their presentation! Austin Hal Murray wrote: > >Then on top of it all, while I am trying to expedite the delivery of a > >few engineering samples of the XC2S150E in the industrial temp range, I > >am told that "BTW, ya know those commercial parts that the distributor > >quoted you 6 week lead time? You won't be getting those any time soon > >either". In fact I received an email from Xilinx support yesterday > >saying that they really haven't even made up their minds yet about > >delivery schedules and won't until the end of May!!! > > Not directed at rickman, but his rant reminded me of an interesting > lesson I learned many years ago. > > New job. I was working on a network board. The group had a person > in charge of the lab and his job included getting parts for prototype > boards like the one I was designing. > > This was back when 4K FIFOs were a big deal and FIFOs were not > yet commodity parts with standard pinouts. > > I had a nice stack of data books. They had various small FIFOs, many > of them marked Advanced or Preliminary (or perhaps wishful thinking). > I wasn't clued into this problem yet so I designed around whatever > seemed best at the time. As my design was getting more real, I > gave Steve a rough cut at a parts list. Soon he reported that some > of the FIFOs I'd picked didn't really exist. No major problem. I > flipped through the books and found another one. That one didn't > exist either. > > After a couple iterations, Steve came by with a couple of parts in > his hand. Samples. This one really did exist. End of problem. > > Ever since that day, "Can you get samples?" was our code word > for "Does it really exist?" If Steve could get samples, I > was happy using it in a design and he was happy too, knowing > that he wouldn't get stuck trying to locate an impossible part > while everybody was breathing down his neck. > > "Samples in hand" has been my rule of thumb ever since. Several > times I have passed it on to new people. > > Of course, it sometimes doesn't work when you are using specialized > parts, like FPGAs and CPUs or big IO chips. But even then it's a > good flag that you might have problems - an issue to put high on > your potential risk list. > > I haven't used bleeding edge Xilinx parts in a long time. They > used to be pretty good about publishing a what/when availibility > chart in XCell. I'd be suspicious if my plans didn't mesh with > that chart, especially if I didn't have samples in hand. > > Obviously, if you have a good relationship with a vendor or > distributor you can sensibly stick your neck out farther. > But it takes a while to establish that trust. > > -- > These are my opinions, not necessarily my employer's. I hate spam.Article: 42765
I think you should use IN5817 since it is a shottky diode. 1N4002 is a regular silicon diode. Forward voltage drop over a shottky is around 0.15..0.25 volts while it is 0.55..0.65 volts for a regular diode. And for voltage detection there are two diodes in series in the programming cable... -- Tuomo Auer "Mark McMahon" <point308@hotmail.com> wrote in message news:f30d4942.0205020128.33e302e4@posting.google.com... > Hello all, > > I've been trying to make my own Xilinx parallel cable III using the > available schematics. My board is double sided, with a male parallel > connector so I can use any parallel cable. > > The differences between my PCB and the original xilinx one are: > (1) D6, Busy and PE are connected on the board, not at the computer > end of the cable. > (2) The tristate buffer is 74HC125A > (3) The diode are 1N4002, not 1N5817. > > I've tried two different board layouts, both of which work sometimes, > depending on which direction the wind is blowing. > I've tried both linear and switch mode power supplies. > If anyone else has successfully implemented this design I would > appreciate some pointers in the right direction. > > Thanks for your help. > Mark.Article: 42766
Hi John. I had similar problems with instantiating the readback component. It's been a while since than, but I think the problem looked about the same. But I was using Xilinx Foundation 3.1i at that time, i.e. synthesis was done using FPGA Express, not Xilinx XST. Can you have a look at the schematic of the synthesized circuit? In my case it was simply broken, the readback component was not connected properly. I tried to manually insert buffers to prevent the tools from optimizing the readback component away, but I couldnt get things right. There were always unconnected ports und nets going to nowhere or starting from nowhere. At some point, I gave up trying to fix these problems. If I remember right, the problems were not present in earlier versions of the the synthesis software, i.e. the problem was only introduced by the installation of a certain service pack. But I'm not sure about that anymore.. Xilinx customer support did also send me VHDL code that should work, but the problems were the same, also with the Xilinx provided code. Regards, Chris John Williams wrote: > Hi, > > I'm using an XC4010E on an XS40 board, and am trying to implement a > simple parallel cable readback interface. I've scoured the Xilinx web > pages, newsgroups, and the web in general, and am having great > difficulty doing what appears on the surface to be fairly > straight-forward. The problem is not the parallel interface, but simply > trying to instantiate a readback block and get the readback going. > > I'm using FPGA Express under ISE4.2i targetting the XC4010E. > > I've tried using both schematic capture and VHDL, and whatever I do, it > seems like the readback block is being "optimised out". I've even tried > attaching dummy logic to the inputs and outputs to force the signals to > remain, but it still happens. There's a Xilinx Answer which proposes > the following VHDL code to implement readback: > -- Christian Plessl remove 'remove' from email-address when replyingArticle: 42767
hi, I'm using the modelsim version 5.5e supplied with Altera's Quartus II toolset. I have been trying to write a test bench. My aim is to read a file with input vectors and assign these vectors to a std_logic_vector signal. How can I convert a "variable IN_BUF : line" type to a std_logic_vector signal. I will probably need some conversion functions, but I don't seem to find anything working. Haven't seen anything in the documentation either. I have pasted a part of my code below. Any help would be appreciated. Thanks, Prashant LIBRARY ieee; USE ieee.std_logic_1164.all; USE std.textio.all; use IEEE.STD_LOGIC_UNSIGNED.ALL; use ieee.std_logic_arith.all; USE ieee.std_logic_textio.all; ENTITY mult16x16_tb1 IS END mult16x16_tb1; ARCHITECTURE mult16x16_arch OF mult16x16_tb1 IS -- constants -- signals SIGNAL t_sig_a : STD_LOGIC_VECTOR(15 DOWNTO 0); SIGNAL t_sig_b : STD_LOGIC_VECTOR(15 DOWNTO 0); SIGNAL t_sig_clk : STD_LOGIC; SIGNAL t_sig_outl : STD_LOGIC_VECTOR(15 DOWNTO 0); SIGNAL t_sig_outm : STD_LOGIC_VECTOR(15 DOWNTO 0); COMPONENT mult16x16 PORT ( a : IN STD_LOGIC_VECTOR(15 DOWNTO 0); b : IN STD_LOGIC_VECTOR(15 DOWNTO 0); clk : IN STD_LOGIC; outl : OUT STD_LOGIC_VECTOR(15 DOWNTO 0); outm : OUT STD_LOGIC_VECTOR(15 DOWNTO 0) ); END COMPONENT; BEGIN tb : mult16x16 PORT MAP ( -- list connections between master ports and signals a => t_sig_a, b => t_sig_b, clk => t_sig_clk, outl => t_sig_outl, outm => t_sig_outm ); a : PROCESS file input: TEXT is in "input.txt"; variable IN_BUF : line; BEGIN while not endfile(input) loop IN_BUF := NULL; READLINE (input,IN_BUF); t_sig_a <= CONV_STD_LOGIC_VECTOR(IN_BUF);-- this is the line that doesn't seem to work. WAIT; end loop; END PROCESS a;Article: 42768
Hi Mark, two suggestions: 1) reflexions / overshoots on the wires between your board and the xilinx chip. Try with shortest wires as possible. 2) reflexions on the cable between the computer and your board. Try with a very short cable. (I have made a slightly different circuit to program a Xilinx CPLD.) good luck! Werner Mark McMahon wrote: > > Hello all, > > I've been trying to make my own Xilinx parallel cable III using the > available schematics. My board is double sided, with a male parallel > connector so I can use any parallel cable. > > The differences between my PCB and the original xilinx one are: > (1) D6, Busy and PE are connected on the board, not at the computer > end of the cable. > (2) The tristate buffer is 74HC125A > (3) The diode are 1N4002, not 1N5817. > > I've tried two different board layouts, both of which work sometimes, > depending on which direction the wind is blowing. > I've tried both linear and switch mode power supplies. > If anyone else has successfully implemented this design I would > appreciate some pointers in the right direction. >Article: 42769
>LIBRARY ieee; >USE ieee.std_logic_1164.all; >USE std.textio.all; >use IEEE.STD_LOGIC_UNSIGNED.ALL; >use ieee.std_logic_arith.all; >USE ieee.std_logic_textio.all; >a : PROCESS >file input: TEXT is in "input.txt"; >variable IN_BUF : line; >BEGIN >while not endfile(input) loop >IN_BUF := NULL; >READLINE (input,IN_BUF); > >t_sig_a <= CONV_STD_LOGIC_VECTOR(IN_BUF); Instead of: ">t_sig_a <= CONV_STD_LOGIC_VECTOR(IN_BUF);" Use Read(in_buf, t_sig_a); -- THis is from the std_logic_textio package Take a look at the boby of the package. ------------------------------------------------------------------------- Ben Cohen Publisher, Trainer, Consultant (310) 721-4830 http://www.vhdlcohen.com/ vhdlcohen@aol.com Author of following textbooks: * Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 0-9705394-2-8 * Component Design by Example ", 2001 isbn 0-9705394-0-1 * VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1 * VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115 ------------------------------------------------------------------------------Article: 42770
This is a multi-part message in MIME format. --------------2F361A617593AF48BA959FE5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We had a similar discussion to this over a year ago and it is currently archieved at the FPGA-FAQ web page at: http://www.fpga-faq.com/FAQ_Pages/0016_Wired_AND_OR.htm I certainly suggest reading this if you are intersted in this subject. I know synthesis tools are always improving and I would not be surprised if some are now taking greater advantage of the carry chain for wide logical functions however I am not aware of any that currently do. As seen in that FAQ page, in VHDL, it is not too difficult to create that structure using some generate statements. I guess it would be just as easy to do in Verilog if your synthesis tool supports the 2001 generate constructs (I just heard synplify 7.1 does) however I have not tried that yet myself (but plan to soon). If you choose the implementation that uses the carry-chain, you are stuck in a vertical orientation which generally is more advantagous than detrimental to most designs. Most arithmetic functions (adder, subtractor, counter, etc.) that could feed or be fed to this logical function(s) will be in the same orientation because of the carry chain. Just be sure the LSB of the logical function is at the bottom as most arithmetic functions map to the carry chain in that manner. In other words, match bus direction. If for some reason you need a horizontal orientation, then you are probably better off staying in LUTs however depending on how wide the function may be, it still might be better to stay on the carry chain and accept slightly longer routes. -- Brian "news.bellatlantic.net" wrote: > Do any of the tools (either the synthesis or mapping stages) support this, > or do you have to create instantiations yourself? > > BTW this would stack the OR inputs "vertically." if you need them > horizontal, perhaps the SOP feature would work? -Stan > > "Peter Alfke" <palfke@earthlink.net> wrote in message > news:3CCB9127.D10CAD92@earthlink.net... > > Any one LUT takes 4 inputs (any function you want). > > You can then concatenate LUTs through the carry chain at no extra cost in > > area, and about 30 ps additional delay per LUT used. > > > > Peter Alfke, Xilinx Applications > > ================================ > > crackeur wrote: > > > > > In static logic, to implement a gigantic OR function, one may instead > stack > > > up multiple layers of OR gates in order to optimize for performance. How > > > does > > > LUT work, is it any different? If I want to implement an OR function > with > > > lots of inputs, does LUT do it better, or in otherwords, how does the > FPGA > > > compiler optimize this using LUTs? > > > > > > Jimmy > >Article: 42771
Kevin Brace wrote: > > I am just wondering, why can't you use XC2S150 instead of XC2S150E? > Is it possible to replace the 1.8V voltage regulator with a 2.5V one for > XC2S150? > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.) Yes, I can do that if you can provide me with a TMS320C6711B that runs from 2.5 volts. :) -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 42772
ussell wrote: > > Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:<aaqifp$lmf$1@newsreader.mailgate.org>... > > I am just wondering, why can't you use XC2S150 instead of XC2S150E? > > Is it possible to replace the 1.8V voltage regulator with a 2.5V one for > > XC2S150? > > You could just use a 1N4001 diode in series with the 3.3V supply > to get ~2.5V. My regulator circuit works like that, except it's > using transistors and zeners to do it. > > Another way would be to use a more available commercial > temp chip, and test 10 boards at a time in an environment > chamber. That might be possible, but I am being told that the commercial temp chips that I expected to be receiving in a few weeks are also not available until August. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 42773
"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag news:3CD16253.FD3CF44A@yahoo.com... > > Another way would be to use a more available commercial > > temp chip, and test 10 boards at a time in an environment > > chamber. > > That might be possible, but I am being told that the commercial temp > chips that I expected to be receiving in a few weeks are also not > available until August. Arent the industrial temp. chips not just the same as the commercial ones, exept that they are selected to run at higher tmeperatures (slower transistors) at the same speed as the commercial ones? So IMHO there are ways to overcome the problem for the prototypes. If your timing analyzer tells you, a commercial chip runs @ 120 Mhz, this can maybe translated to 100MHz operation of a industrial version. You could also tweeak the core voltage to the upper end (+5%) to do you test and "simulate" the industrial versions. Or just test on lower temperatures, extrapolating the (unfurunately not available) industrial speed grades. Yes, this is all a little bit experimental and not fully covered by the datasheets. But as Peter said. "No Guts, no glory" -- MfG FalkArticle: 42774
You might try our Hotman product http://www.vcc.com/hmSet1.html . We've been working on with the xilinx download cable for a few months and we seem to be able to configure and readback with no problem. You need to download the driver from http://www.driverlinx.com/Software_Products/softwareproducts.htm You might just be able use the driver with what you have already written, it seems very robust. Steve C "Jens Frauenschlaeger" <conny@informatik.uni-leipzig.de> wrote in message news:aar1j7$ln5$1@news.uni-leipzig.de... > Hi, > finally someone who has a quite similar problem with JTAG. :) > I see you try to configure a fpga with a self-build harware and your own > device driver. Thats nearly the same i do. > And my attempts behave strange too. > Apart from the fpga (i use a 800th virtex) and the cable (lately we bought a > PC IV - which is able to simulate the same behaviour > as the PC III), i use W2k too...basically hardly any difference. > I suppose either you made a mistake at your own cable or you forgot to force > a driver pin(e.g. pin 5). > > What about sharing our knowledge and cut the problems in half ? > > > cheers, > Jens > > > > -------------------------------------------------------------------------- -- > ----------------------------------------- > Jens Frauenschlaeger, <conny@informatik.uni-leipzig.de> > University of Leipzig > Germany > > > >
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