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
Hi, According to the Xilinx literature their PCI cores are not synthesisable by their own XST VHDL compiler. Does anyone know why this is? Has anyone tried synthesising Xilinx PCI cores using XST? I've been using their web pack and the XST seems very capable. I'm also just on the verge of ordering my VHDL tool chain for a PCI based design so I need to know whether I need to buy a third party VHDL compiler. Regards, Parps. parps@ic24.netArticle: 35802
Can anybody give the internal timing diagrams of 8051 what happens during each clock cycleArticle: 35803
sudin wrote: > Can anybody give the internal timing diagrams of 8051 what happens > during each clock cycle Which 8051? About 30 companies make clones... TomArticle: 35804
The hardware field (and the SW field too) is growing faster than anyone can keep up. Your knowledge is decayable, you have to refill completely within 10 years. This means you cannot base a career on one technology. You have to start learning new things every day. You can call yourself an experienced hardware engineer when you spent 10 years in the field doing whatever. This whatever determines what you're doing. Have a look at everything. BTW software engineering and hardware engineering is not exclusive, they fit each other nicely. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com Jack wrote: > > Hi everyone. > I'm a software engineer and graduating soon for my MSEE. > I would like to make a career change to hardware design, since i'm > more interested in hardware design now after taking advanced computer > architecture courses, advanced logic design, and other hardware > related courses. > Also, I'm learning verilog and xilinx fpga now. > > What do you suggest me to learn specifically to land a job in > fpga/asic designer, especially for new guy like me? (such as, pci bus > design, risc machine, etc) > or any advice what to start, roadmap, and everything you can advice. > > Thanks so much. I'd appreciate any help. > > JackArticle: 35805
henk@bliek.demon.nl (Henk Bliek) writes: > On 16 Oct 2001 08:59:07 +0100, Martin Thompson > <martin.j.thompson@trw.com> wrote: > > > > SCL_IN_signal <= SCL_pin; SCL_pin <= '0' when SCL_OUT_signal = '0' > >else 'Z'; > > > > This synthesises to a birdirectional pin with an open-drain driver. > > > Why should this not translate into a push-pull buffer. Or is this > specified to become an OD in an altera device? As far as I know this > becomes a normal LVTLL threestate pin on a Xilinx S2. > > regards, Henk Because SCL_pin is never assigned a '1'. Synplify infers this to be a tristate driver, but the Altera tool then sees it as an open drain. Even if it didn't it would still behave as such because it never drives a '1'. In fact, that may even be what happens... Cheers, Martin -- martin.j.thompson@trw.com TRW Automotive Technical Centre, Solihull, UKArticle: 35806
tony_kirke@yahoo.com (Tony Kirke) writes: > I need an ~100 MHz SDRAM controller core for 64 bit/256 Mbytes SDRAM. > Does anyone have any recommendations on using either the Xilinx > references or acquiring 3rd party IP for the task? Thanks I wrote one with a very similar spec to this for my task, its not very generic at the moment, but it might be genericable. Alternatively, Altera has free source, and Xilinx probably does. They'll probably work fine at 100MHz in the faster parts. Cheers, Martin -- martin.j.thompson@trw.com TRW Automotive Technical Centre, Solihull, UKArticle: 35807
Paul Teagle schrieb: > > Related to the recent DLL/PLL discussions, are there any measured figures on > phase noise performance for the DLL/PLL. Are phase noise figures specific to There are pares from both sides, with both sides showing themself as the winner ;-) This discussion is not new, and at the end of the last one, the conclusion was that the measurements were not fully correct on BOTH sides and that they were more or less theoretical, because in a real design jitter performance is strongly influenced by board layout, noise sources near your board, and noise sources inside the FPGA (switching FlipFlops) -- MFG FalkArticle: 35808
Hi all, I'm working on a university project invloving using Firewire (IEEE 1394) interfaces for input and output from an FPGA-based video processing board. The firewire will form a link from a DV camera to the board, and from the board to a PC/workstation. Does anyone have any reccomendations for physical layer interfaces and link layer controller devices? I've found the Altera IP for FPGA-based LLCs, but would prefer to have an external device if possible, as I need all the logic resources for other things. Also, has anyone else done this kind of thing before? If so, any hints/tips/links would be handy. Thanks, Ben.Article: 35809
Does anybody encounter problem with VirtexII ES during configuration in Slave Select Map. The errata sheet mention something about the timings of CS_B and RDWR_B...Article: 35810
Thanks so much for your response. I must admit that I like your approach better. I am something of a beginner so I tend to take the brute force approach. Yours is much better for the kinds of signals I need to use for simulation. A second question comes to mind. I have a system with two boards. Each board has one FPGA. Board 1 supplies _most_ but not all of the test signals for board 2. I would like to use the output of board 1 as test vectors for board 2. I am using web-pack. Is there a way to separately compile each FPGA and yet use a single test bench to run the simulation? What about if I went to the full version of the software? (i.e. Foundation ISE or equiv.)? Jonathan Bromley wrote: > In article <3BCD90F5.B1307FD4@egr.msu.edu>, Theron Hicks > <hicksthe@egr.msu.edu> writes > >I have what is a very simple question. Is there a way to write a long > >line of VHDL code on 2 or more lines? In particular, I am writing a > >test bench where a clock signal must be described. This signal is off > >for the first microsecond and the clocks eight times in the second > >microsecond at 50 ns per half cycle. > > > > How about > > clk <= '0', > '1' after 1000 ns, > '0' after 1050 ns, > '1' after 1100 ns, > > etc, etc? That's fine. VHDL is a free-form language; you can > have a new line in the source-code anywhere you could normally > have a space (except, of course, in the middle of a quoted string). > > OTOH this is a gruesome way to describe your clock, isn't it? > Don't you prefer this? > > ClockGenerator : process > constant Clock_Start_Delay: time := 1 us; > constant Period: time := 100 ns; > constant NumPulses: integer := 8; > begin > clk <= '0'; > wait for Clock_Start_Delay; > for i in 1 to NumPulses loop > clk <= '1', '0' after Period/2; > wait for Period; > end loop; > wait; > end process; -- ClockGenerator > > OK, it's longer (just!), but I know which I would prefer to write, and > (far more importantly) which I'd prefer to modify three months later. > > HTH > -- > Jonathan Bromley > DOULOS Ltd. > Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom > Tel: +44 1425 471223 Email: jonathan.bromley@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: 35811
RS, The errata sheet is correct. If the timings are not as they are stated, it will not configure. Contact your FAE for all of the details. They have a more lengthy explanation of all errata items, and all of the workarounds and fixes. Austin RS wrote: > Does anybody encounter problem with VirtexII ES during configuration > in Slave Select Map. The errata sheet mention something about the > timings of CS_B and RDWR_B...Article: 35812
Jack wrote: . . . > Also, I'm learning verilog and xilinx fpga now. > > What do you suggest me to learn specifically to land a job in > fpga/asic designer, especially for new guy like me? > (such as, pci bus design, risc machine, etc) > or any advice what to start, roadmap, and everything you can advice. Flexibility is the key. I would recommend learning: 1. verilog and vhdl simulation 2. verilog and vhdl synthesis 3. windows and unix shell 4. a cross-platform scripting language (perl, Tcl/Tk, emacs-lisp etc.) I don't think the specific project application matters too much. Probably best to pick something of interest and keep improving the design and testbenches so that you learn the tools completely. --Mike TreselerArticle: 35813
Hi I suggest that You have a look at the HTTP of the producer of the specific 8051 that You use. In case of a DALLAS there are 3 different types using 12, 4 or 1 clock-cycle pr. instruction. The DALLAS, which is the fastest today, may be found as the MAXIM-page as they have been merged. (one does not have to guess that i am in favour of the DALLAS) Best regards IvarArticle: 35814
Look at TI's web. They have a lot of IEEE-1394 chips for physical layer, link layer and integrated controllers. The site is: http://focus.ti.com/docs/prod/productlist.jhtml;$sessionid$USP3DQQAACOCDTMNZ SFBF2Q?familyId=534&templateId=5 "Ben" <seabybs@hotmail.com> wrote in message news:ZzDz7.4313$sF.480126@news2-win.server.ntlworld.com... > Hi all, > I'm working on a university project invloving using Firewire (IEEE 1394) > interfaces for input and output from an FPGA-based video processing board. > The firewire will form a link from a DV camera to the board, and from the > board to a PC/workstation. > > Does anyone have any reccomendations for physical layer interfaces and link > layer controller devices? I've found the > Altera IP for FPGA-based LLCs, but would prefer to have an external device > if possible, as I need all the logic resources for other things. > > Also, has anyone else done this kind of thing before? If so, any > hints/tips/links would be handy. > > Thanks, > Ben. > > >Article: 35815
For anybody interested in some deadly glitches, have a look at www.burned-fuses.de beside the non-sense links ;-) you will find a link to the glitch datas. But its still preliminary. -- MFG FalkArticle: 35816
--------------E014E88FB0631AB7E2329D0F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Falk, Guten Tag! And why is a measurement made on the board with IOs and FFs switching not real? http://www.xilinx.com/products/virtex/techtopic/vtt013.pdf I agree that one must make real measurements in the real world of customers' designs. (Even competitors' designs!) As a practice, we take 70% of the FF's, toggle them from an asynchronous clock, and max out the IO's with the guideline for SSO's, and THEN we look a the jitter. While this isn't your design, it isn't the worst, nor is it the best either. The asynchronous clocking of the IOs and FFs really does hurt, however, and a completely synchronous (one clock) design will obviously be cleaner. I don't think I have seen a single clock design for three years now, however.... Oh, we also use our own bypass and layout guidelines, and have the best signal integrity we get get on all of the signals ... no reason to show ourselves in a poor light. Seriously, there was a time when no one bothered with jitter, as 200 to 400 ps was not enough to be noticed with a 66 MHz clock. At 311.04 MHz, suddenly a few hundred picoseconds is a significant part of the entire timing budget, affecting eye opening, timing margin internally, and data recovery integrity by other IC's on the pcb. Control of this budget is the topic of some literature that we will be publishing shortly. The second in the series on jitter will follow this one soon: http://www.xilinx.com/support/techxclusives/jitter-techX10.htm Check out the ICS8745 LVDS PLL/Buffer-Driver as a means of reducing jitter 100 fold for critical applications. http://www.icst.com/pdf/ics8745.pdf With a pole at ~1.4 MHz, and the DCM (DLL) jitter at from 1/768 to 1/6th the clock rate (programmable - of course), it is a brick wall jitter filter when used with a Virtex, Spartan II, Virtex E, or Virtex II part. Looked at it in the FPGA Lab yesterday, and we were quite impressed with its performance. Since the jitter from the other guys PLL is low frequency, it doesn't help clean it up (ie little jitter attenuation of another noisy PLL). Winning is what our goal is for your design, if it needs a PLL, that is OK with me. ICS seems to make some really good ones that provide an excellent match to the DCMs charateristics. As usual, a PLL is an analog animal, and there are specific layout and bypassing rules that need to be observed. The LVDS inputs and outputs help provide for a much lower jitter solution as well, making the use of the part much less sensitive than a single ended i/o solution. Austin Falk Brunner wrote: > Paul Teagle schrieb: > > > > Related to the recent DLL/PLL discussions, are there any measured figures on > > phase noise performance for the DLL/PLL. Are phase noise figures specific to > > There are pares from both sides, with both sides showing themself as the > winner ;-) > This discussion is not new, and at the end of the last one, the > conclusion was that the measurements were not fully correct on BOTH > sides and that they were more or less theoretical, because in a real > design jitter performance is strongly influenced by board layout, noise > sources near your board, and noise sources inside the FPGA (switching > FlipFlops) > > -- > MFG > Falk --------------E014E88FB0631AB7E2329D0F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Falk, <p>Guten Tag! <p>And why is a measurement made on the board with IOs and FFs switching not real? <p> <a href="http://www.xilinx.com/products/virtex/techtopic/vtt013.pdf">http://www.xilinx.com/products/virtex/techtopic/vtt013.pdf</a> <p>I agree that one must make real measurements in the real world of customers' designs. (Even competitors' designs!) <p>As a practice, we take 70% of the FF's, toggle them from an asynchronous clock, and max out the IO's with the guideline for SSO's, and THEN we look a the jitter. While this isn't your design, it isn't the worst, nor is it the best either. The asynchronous clocking of the IOs and FFs really does hurt, however, and a completely synchronous (one clock) design will obviously be cleaner. <p>I don't think I have seen a single clock design for three years now, however.... <p>Oh, we also use our own bypass and layout guidelines, and have the best signal integrity we get get on all of the signals ... no reason to show ourselves in a poor light. <p>Seriously, there was a time when no one bothered with jitter, as 200 to 400 ps was not enough to be noticed with a 66 MHz clock. <p>At 311.04 MHz, suddenly a few hundred picoseconds is a significant part of the entire timing budget, affecting eye opening, timing margin internally, and data recovery integrity by other IC's on the pcb. <p>Control of this budget is the topic of some literature that we will be publishing shortly. The second in the series on jitter will follow this one soon: <p> <a href="http://www.xilinx.com/support/techxclusives/jitter-techX10.htm">http://www.xilinx.com/support/techxclusives/jitter-techX10.htm</a> <p>Check out the <b>ICS8745 LVDS PLL/Buffer-Driver</b> as a means of reducing jitter <b>100 fold</b> for critical applications. <p> <a href="http://www.icst.com/pdf/ics8745.pdf">http://www.icst.com/pdf/ics8745.pdf</a> <p>With a pole at ~1.4 MHz, and the DCM (DLL) jitter at from 1/768 to 1/6th the clock rate (programmable - of course), it is a brick wall jitter filter when used with a Virtex, Spartan II, Virtex E, or Virtex II part. <p>Looked at it in the FPGA Lab yesterday, and we were quite impressed with its performance. <p>Since the jitter from the other guys PLL is low frequency, it doesn't help clean it up (ie little jitter attenuation of another noisy PLL). <p>Winning is what our goal is for your design, if it needs a PLL, that is OK with me. ICS seems to make some really good ones that provide an excellent match to the DCMs charateristics. <p>As usual,<b> a PLL is an analog animal</b>, and there are specific layout and bypassing rules that need to be observed. The LVDS inputs and outputs help provide for a much lower jitter solution as well, making the use of the part much less sensitive than a single ended i/o solution. <p>Austin <p>Falk Brunner wrote: <blockquote TYPE=CITE>Paul Teagle schrieb: <br>> <br>> Related to the recent DLL/PLL discussions, are there any measured figures on <br>> phase noise performance for the DLL/PLL. Are phase noise figures specific to <p>There are pares from both sides, with both sides showing themself as the <br>winner ;-) <br>This discussion is not new, and at the end of the last one, the <br>conclusion was that the measurements were not fully correct on BOTH <br>sides and that they were more or less theoretical, because in a real <br>design jitter performance is strongly influenced by board layout, noise <br>sources near your board, and noise sources inside the FPGA (switching <br>FlipFlops) <p>-- <br>MFG <br>Falk</blockquote> </html> --------------E014E88FB0631AB7E2329D0F--Article: 35817
> I used Insight Electronics Spartan-II PCI development board which has > Xilinx Spartan-II 150K system gates part (XC2S150, speed grade -5, 208 > pin PQFP package) on it with 8MB of SDRAM on board for only $145 > without Xilinx PCI LogiCORE license. > Very nice board considering the price, but I guess I wish they used > speed grade -6 instead of -5. I tried to find this board on Insight's web site without success. Do you have a part number? TomArticle: 35818
John - We only offer our cores (including PCI) as netlists - not as HDL source for synthesis... - Mark John Smith wrote: > Hi, > > According to the Xilinx literature their PCI cores are not synthesisable by > their own XST VHDL compiler. Does anyone know why this is? Has anyone tried > synthesising Xilinx PCI cores using XST? > > I've been using their web pack and the XST seems very capable. I'm also just > on the verge of ordering my VHDL tool chain for a PCI based design so I need > to know whether I need to buy a third party VHDL compiler. > > Regards, > > Parps. > parps@ic24.net -- Mark Aaldering Sr. Director IP Solutions Division (408) 879-6980; Mark.Aaldering@xilinx.comArticle: 35819
Yup, found all the TI stuff before. Just wondering if anyone had any reccomendations for other vendors' chipset. Thaks for that, Ben. "Jan Pech" <j.pech@sh.cvut.cz> wrote in message news:9qn60h$2in2$1@ns.felk.cvut.cz... > Look at TI's web. They have a lot of IEEE-1394 chips for physical layer, > link layer and integrated controllers. The site is: > http://focus.ti.com/docs/prod/productlist.jhtml;$sessionid$USP3DQQAACOCDTMNZ > SFBF2Q?familyId=534&templateId=5 > > "Ben" <seabybs@hotmail.com> wrote in message > news:ZzDz7.4313$sF.480126@news2-win.server.ntlworld.com... > > Hi all, > > I'm working on a university project invloving using Firewire (IEEE 1394) > > interfaces for input and output from an FPGA-based video processing board. > > The firewire will form a link from a DV camera to the board, and from the > > board to a PC/workstation. > > > > Does anyone have any reccomendations for physical layer interfaces and > link > > layer controller devices? I've found the > > Altera IP for FPGA-based LLCs, but would prefer to have an external device > > if possible, as I need all the logic resources for other things. > > > > Also, has anyone else done this kind of thing before? If so, any > > hints/tips/links would be handy. > > > > Thanks, > > Ben. > > > > > > > >Article: 35821
Hello, I have made my diploma thesis about FireWire. The problem is, that you need an IEEE 1394 chipset, that is ideal for your application. If you will send data from an camera, then you can use link layers from philips, because they have an port for audio and video signals. Also you can look at TI and Fujitsu, Sony and NEC. Christoph Ben schrieb: > Hi all, > I'm working on a university project invloving using Firewire (IEEE 1394) > interfaces for input and output from an FPGA-based video processing board. > The firewire will form a link from a DV camera to the board, and from the > board to a PC/workstation. > > Does anyone have any reccomendations for physical layer interfaces and link > layer controller devices? I've found the > Altera IP for FPGA-based LLCs, but would prefer to have an external device > if possible, as I need all the logic resources for other things. > > Also, has anyone else done this kind of thing before? If so, any > hints/tips/links would be handy. > > Thanks, > Ben.Article: 35822
I seem to be having problems getting XST (from WebPack 4) to synth block rams.
Here is the source:
// Synchronous Single Port Block RAM
module SPBRAM (data_in, data_out, address, we, clock);
input [15:0] data_in;
input [13:0] address;
input we, clock;
output [17:0] data_out;
reg [15:0] data [16383:0];
reg [13:0] address_reg;
assign data_out = data[address_reg];
always @(negedge clock) begin
address_reg <= address;
if (we) begin
data[address] <= data_in;
end
end
endmodule
The synthesis takes an inordinate amount of time (hours) and I'm not sure the
output is correct since map tends to choke too. AFAIK, this code is ok.
Also, when I try to use the 2 parity lines to create 18-bit RAM, XST ends up
"chaining" blocks to get 18 bits..messy.
I could always use coregen, but I'd like to see if it's possible to use
plain Verilog first.
Any suggestions?
Eric LaForest
Article: 35823
I get the following Timing Constraint not met message:
Asterisk (*) preceding a constraint indicates it was not met.
----------------------------------------------------------------------------
----
Constraint | Requested | Actual |
Logic
| | |
Levels
----------------------------------------------------------------------------
----
* TS_CLK20MHZ = PERIOD TIMEGRP "CLK20MHZ" | 50.000ns | 28.049ns | 11
50 nS HIGH 50.000000 % | | |
----------------------------------------------------------------------------
----
Sorry the spacing is kind of messed up. What it says is Requested period is
50.000ns, and actual is 28.049ns. Is this supposed to mean that 28.049ns is
half my actual period? If not, I'd say I met the timing constraint, why is
it giving me an error?
Thanks,
Dave
Article: 35824
Dave Brown wrote:
>
> I get the following Timing Constraint not met message:
>
> Asterisk (*) preceding a constraint indicates it was not met.
>
> ----------------------------------------------------------------------------
> Constraint | Requested | Actual |
> Logic
> | | |
> Levels
> ----------------------------------------------------------------------------
> * TS_CLK20MHZ = PERIOD TIMEGRP "CLK20MHZ" | 50.000ns | 28.049ns | 11
> 50 nS HIGH 50.000000 % | | |
> ----------------------------------------------------------------------------
>
> Sorry the spacing is kind of messed up. What it says is Requested period is
> 50.000ns, and actual is 28.049ns. Is this supposed to mean that 28.049ns is
> half my actual period? If not, I'd say I met the timing constraint, why is
> it giving me an error?
Check your constraint file.
Looks to me like you have a duty cycle constraint
of (High < 50% of clock period)
--Mike Treseler
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