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
Paul Smith wrote:
>
> Another base register points to a data FIFO. In our application, we
> don't know ahead of time how much data will be in this FIFO. The hope
> was to poll this FIFO with a burst read. Most of the time the FIFO
> should be empty, so we want 0 words to be returned. When the FIFO
> contains data we want to read all its words. Since this can vary, we
> want to use the PCI STOP signal to have a target-initiated termination.
>
> This seems to be much harder than we hoped. We haven't figured out how
> to do a PCI burst read under linux. A series of single reads sort of
> works, but hangs up the computer when there is no data in the FIFO.
>
You should be aware that in most (almost all) x86-based systems
with PCI, the microprocessor (CPU) cannot initiate a burst read to a PCI
device.
The only way to do a burst read will be to let a bus master (initiator)
device to do it.
However, microprocessors can do a burst write though. (Typically, it
will do a write burst of 4 to 8 DWORDS.)
Regards,
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 43026Kevin Brace wrote: > > Paul Smith wrote: > >>This seems to be much harder than we hoped. We haven't figured out how >>to do a PCI burst read under linux. A series of single reads sort of >>works, but hangs up the computer when there is no data in the FIFO. > > You should be aware that in most (almost all) x86-based systems > with PCI, the microprocessor (CPU) cannot initiate a burst read to a PCI > device. As paul has discovered, host processor PCI bridges tend to combine accesses, if the region is prefetchable, but Kevin is right that this cannot be depended on, even in embedded systems. The target device really should support bus mastering writes. Anything other will be nothing but trouble given what is apparently being attempted. Does theXilinx PCI support support bus mastering? -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, steve at picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." abuse@xo.com uce@ftc.govArticle: 43027
Antonio,
Congratulations. I know you have worked hard.
Antonio wrote:
> Yesterday I discuss my Thesis regarding a QPSK modulator for space
> application implemented on XCV1000, it have the maximum of the score
> and this is also due to your help, I would want to say thanks to all
> of you but expecially to:
>
> Allan Herriman for the initial idea on the architecture of the
> modulator,
> Ray Andraka for the support in the implementation on FPGA
> Brian Philopsky for its precision answering to unusual questions
> Jacky Renaux for its support using Blockram
> Peter Afke for its short answers
>
> but I repeat, thanks to all of you 'cause I produced my Thesis and at
> the same time I work for a software company so you were my only
> technical reference, thanks to the newsgroup institution
>
> Antonio D'Ottavio
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 43028
You can store your 'easter egg' serially in an SRL16 wrapped back on itself
and use the serial UART clock to clock it out. Include the start and stop
bits and then you just need to mux between the Uart and yourSRL16.
Theron Hicks wrote:
> Hi,
> I am in the process of finalizing an FPGA design and am considering
> adding an "easter egg" in the design. In particular, I need to document
> the design as "mine". The product is an instrumnet and includes a very
> simple microcontroller and a UART implemented in the FPGA. (Thanks to
> Ken Chapman for his UART and KCPSM, XAPP213 and XAPP223.) The product
> will be controlled via the serial port of a PC. I can either have it
> echo back the corporate name and the year ("DFTI 2002") at power up, or
> as a response to a control string sent via the serial port. i.e. send
> "who" via the serial port and then echo "DFTI 2002". Any comments?
>
> Thanks,
> Theron Hicks
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 43029Burst reads have nothing to do with the processor but the chip sets. On the alpha target burst reads are no problem. Intel's chip set does not do burst reads. Yes the Xilinx PCI can be a bus master. Steve > > You should be aware that in most (almost all) x86-based systems > > with PCI, the microprocessor (CPU) cannot initiate a burst read to a PCI > > device. > > Does theXilinx PCI support support bus mastering?Article: 43030
To collect information from customers regarding Xilinx documenation, I have created a short (10 minute) email survey. If you are interested in providing feedback, please contact me and I will send you the survey. Thanks! Robert Binkley Xilinx Applications robert.binkley@no_pam_xilinx.comArticle: 43031
Peter Alfke <Peter.Alfke@xilinx.com> writes: >One reason we are not too eager to volunteer these numbers is that they >often are being abused for a strange purpose, namely to calculate Mean Time >Between Failure (MTBF). >There still exists a misguided opinion, especially in military circles, that >transistor count directly affects (un)reliabilty. >Nothing could be further from the truth. Transistors well inside the chip >hardly ever fail, I/O transistors are far more likely to fail. Another case of assuming something is statistically independent when it likely isn't. -- glenArticle: 43032
Ray Andraka wrote: Ray, you sound surprisingly knowledgeable on the subject :-) SimonArticle: 43033
Jim Granville <jim.granville@designtools.co.nz> wrote in message news:<3CD9DC3D.697F@designtools.co.nz>... > Russell wrote: > > > > http://www.eetimes.com/story/OEG20020507S0033 > > I also came across this recently, > > http://www.research.microsoft.com/fse/asml/ > > and it seemed to me, this could have FPGA applications. > > A key weakness of C, is the sequential nature of all descriptions, > and the fact that FPGA "C's" are not C at all, but are some > 'variant of the C programming language' - they seem more keen > on getting the magic buzzword C in there, than in how it can be used > practically. Throwing thousands of HW novice C coders at FPGAs sounds > more a problem than a solution :-) > > ASML is inherently parallel, until 'step' in invoked, and thus > the SAME source could potentially target an OpCode or FPGA at runtime. > > This from the overview > > It is only after a step has been made that the new values > > become visible. > > In general, a computation in AsmL is not sequential unless > > explicitly marked as being so. > > ASML would encourage 'sea of CPU' innovations on the PC, as well as > FPGA implementations. > Because it has a path to compile -> Runs on a PC, that also gives a > Simulation path, to verify the logic on FPGA. It looks promising. I've thought myself that the next step in computer evolution would be compilers that generate an executable that not only have sequential cpu instructions, but contain hardware configuration instructions too. The computer would have a simple 'controller' cpu and a large amount of configurable logic. The compiler would generate a cpu core (or simple state machine) and matching instructions for parts of your program that have large amounts of sequential instructions (like a process in vhdl), and it would generate another core instance for every part of your program that can run concurrently. I guess the operating system for such an architecture would be controlling partitioning of the configurable logic, and controlling access to 'hard' peripherals etc.Article: 43034
Jeff Mock wrote:
>
>
> You know, this is a big problem and it's been around for many years.
> It's a problem in any design where you need fast OE performance,
> ZBT SRAMS, fast SDRAMs, etc. I'm surprised Xilinx hasn't fixed this
> long ago, I've complained to the support hotline on two different
> projects.
>
Were you using XST back then?
It sounds like that since you were complaining to Xilinx.
Do you know how other synthesis tools support duplicating IOB FFs
without I/O pads?
Not that it solves anything, but I am not surprised that this is not
only my problem, and other users have also experienced this issue.
> I think it's horrible to resort to instancing primitves, especially
> if you're trying to make the design portable.
>
Yes, it is horrible when I have to instantiate 50 or so I/O pads
of the top level module just to attach an IP core with I/O pads.
> Here's how I work around the problem. I make a separately compiled
> dummy module called oehack. By making an instance of oehack XST is
> faked out because it doesn't know the connectivity and can't optimize
> out the OE flip-flops you're trying to keep:
>
> module oehack (
> oe,
> data_oe
> );
> input oe;
> output [63:0] data_oe;
>
> assign data_oe = { 64 {oe} };
> endmodule
Unfortunately, your solution won't solve my problem since I
don't know the net (wire) leading to a FF I want it duplicated.
Only the synthesis tool knows that.
Here is how I solved the problem.
I decided to install WebPACK ISE 3.3 (Now it is called ISE WebPACK, but
I guess it doesn't matter.) which also comes with XST to my computer
where I already got ISE WebPACK 4.2.
I read some time ago that XST with WebPACK ISE 3.3 generates an EDIF
file instead of an encrypted .NGC file (The XST since ISE 4.1 does so,
unfortunately.), so I will manually edit the netlist to duplicate FFs.
The result is, when I tested it, NGDBUILD correctly read my PCI IP core
in a netlist, and MAP correctly pushed FFs I duplicated by hand into
IOBs.
The only problem is, it takes about 2 to 3 hours to duplicate all 95 or
so FFs by hand, but that's much better than not being able to edit an
encrypted netlist (.NGC file) at all.
Thanks,
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 43035Shane Mulligan wrote: > All I know is that I think there are only two possible ways this can be > achieved. > > a) See I'm trying to figure out if I need a master state machine in the PCI... > > or > > b) The ethernet adapther receives the packet and notifies the pci core.... My advise would be to keep it as simple as you can. That would imply a Target only PCI. There is plenty of things to learn in doing a timing-correct, single word at a time PCI core, and a 10 megabit only Ethernet MAC. (Perhaps a 100 megabit only Ethernet might be just about as easy). Once you get these to work, you would be ready to try something more complex. First attempt at designing FPGAs are often not very good, and by applying what you learn in later designs you will do much better. -- Phil HaysArticle: 43036
sweir wrote:
>
> Kevin,
>
> I think you have at least two options that should work:
>
> 1. Include the I/O pads in the IP core. It is then completely
> self-contained, and the OE FF's will be in the IOB with the bus FF's.
>
> 2. Make a source module for only the I/O portion. Using generates, it
> should be straight forward to get exactly the I/O that you want.
>
> Regards,
Here is how I solved the problem.
I decided to install WebPACK ISE 3.3 (Now it is called ISE WebPACK, but
I guess it doesn't matter.) which also comes with XST to my computer
where I already got ISE WebPACK 4.2.
I read some time ago that XST with WebPACK ISE 3.3 generates an EDIF
file instead of an encrypted .NGC file (The XST since ISE 4.1 does so,
unfortunately.), so I will manually edit the netlist to duplicate FFs.
The result is, when I tested it, NGDBUILD correctly read my PCI IP core
in a netlist, and MAP correctly pushed FFs I duplicated by hand into
IOBs.
The only problem is, it takes about 2 to 3 hours to duplicate all 95 or
so FFs by hand, using a text editor, but that's much better than not
being able to edit an encrypted netlist (.NGC file) at all.
Thanks,
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 43037
Yes, we celebrate Easter every year in my family :-)
Actually, I've used such an animal as a compact ID code that got
sent out a serial port as part of the initialization. The
circuit in my case was two SRL16's, one initialized with the ID
code plus start and stop bits, one initialized as a 1 hot
state. They were enabled by the DDS that generated the transmit
baud rate, so the ID logic only took up one CLB beyond what ws
needed for the UART
Simon Gornall wrote:
> Ray Andraka wrote:
>
> Ray, you sound surprisingly knowledgeable on the subject :-)
>
> Simon
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin,
1759
Article: 43038[context is picking regulator chips] >Avoid parts that say things like "high speed" as the FPGA is not an >Intel chip, and doesn't require 20 amperes in 100 ns. Doesn't that depend upon the design? Seems reasonable to me for the supply current to swing wildly. Consider a high speed design that uses clock enables to conserve power. That could bang-bang in a big way. Either the regulator has to track the usage or you have to have a big pile of caps to do the work. Even if the current is steady once the FPGA gets going, you still have to get over the transient of next-to-nothing to full load when the chip comes out of configuration. If your load fluctuates, it's worth double checking the regulator transient response. DC-DC "brick" type converters often have troubles in this area. (Thank goodness that all the data sheets I've looked at recently at least have some data.) I think it's basically a hard problem. I haven't checked the fine print for linear regulators recently. I got burned with a low-dropout regulator a couple of years ago. Maybe it was ultra-low. It worked if I added enough dummy load. Without that, it shutdown when I ran a test pattern with the clock set within a particular frequency range. I never did underestand it, even with some help from an apps guy. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 43039
> Here is how I solved the problem. >I decided to install WebPACK ISE 3.3 (Now it is called ISE WebPACK, but >I guess it doesn't matter.) which also comes with XST to my computer >where I already got ISE WebPACK 4.2. >I read some time ago that XST with WebPACK ISE 3.3 generates an EDIF >file instead of an encrypted .NGC file (The XST since ISE 4.1 does so, >unfortunately.), so I will manually edit the netlist to duplicate FFs. >The result is, when I tested it, NGDBUILD correctly read my PCI IP core >in a netlist, and MAP correctly pushed FFs I duplicated by hand into >IOBs. >The only problem is, it takes about 2 to 3 hours to duplicate all 95 or >so FFs by hand, using a text editor, but that's much better than not >being able to edit an encrypted netlist (.NGC file) at all. Every now and then, I try to write down a checklist for the ultimate tool set... That story is a good example of one of the important items: Intermediate files have to be in a format that can be processed by user written code. This requires documentation of the file formats. 2 or 3 hours to write the program would avoid the manual editing the next time. All tool sets have warts like this. Being able to write some code to do that sort of transformation would save a lot of headaches. Of course, the next item on the list is that it has to be easy to merge that user-written code into the build procedure. I think that requires something like make - or rather the information needed to write a Makefile. That needs an understanding of which program reads which files and what files it produces. Are .NGC files really encrypted? If so, is that serious encryption or just security by obscurity? I'm happy if mainline tools use binary format files rather than text (say to speed up reading/writing) as long as there is a binary-ascii translator and the reverse. Or maybe just a good description of the file format so I can process it in binary too. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 43040
>Jim Granville <jim.granville@designtools.co.nz> wrote: (snip) >> >> A key weakness of C, is the sequential nature of all descriptions, >> and the fact that FPGA "C's" are not C at all, but are some >> 'variant of the C programming language' - they seem more keen >> on getting the magic buzzword C in there, than in how it can be used >> practically. Throwing thousands of HW novice C coders at FPGAs sounds >> more a problem than a solution :-) >> >> ASML is inherently parallel, until 'step' in invoked, and thus >> the SAME source could potentially target an OpCode or FPGA at runtime. >> >> This from the overview >> > It is only after a step has been made that the new values >> > become visible. >> > In general, a computation in AsmL is not sequential unless >> > explicitly marked as being so. >> >> ASML would encourage 'sea of CPU' innovations on the PC, as well as >> FPGA implementations. >> Because it has a path to compile -> Runs on a PC, that also gives a >> Simulation path, to verify the logic on FPGA. and then rjshaw@iprimus.com.au (russell) writes: (snip) This does sound pretty nice. I have always thought the idea of C to FPGA compilers was pretty useless. The only way I would see it as useful is if you could use the same code, but that doesn't seem likely. Personally, verilog is C-like enough for me. But yes, a language that says that you can do these operations in parallel could be useful. I still think more for parallel processors than for FPGA, but we will just have to wait and see. -- glenArticle: 43041
Tim wrote: > Hal Murray wrote > > > Any estimates on the cost of using "a few" blind vias for something > > like this? > > Not as much as it used to be :) Fairly mainstream technology now. > > A couple of months ago I got an estimate of the PCB cost increase when using blind/buried at about 15% over standard PTH. AFAIK basic, irreducible, extra cost arises from the fact that when going B&B the layers have to be drilled before bonding instead of being able to stack up & drill a whole bunch of already bonded boards. Interestingly the cost per extra layer pair was about the same so from the point of view of overall PCB routability B&B isn't an obvious win.Article: 43043
"Hal Murray" <hmurray-nospam@megapathdsl.net> schrieb im Newsbeitrag news:udmhnffkhg51d7@corp.supernews.com... > [context is picking regulator chips] > > >Avoid parts that say things like "high speed" as the FPGA is not an > >Intel chip, and doesn't require 20 amperes in 100 ns. > Doesn't that depend upon the design? Seems reasonable to me > for the supply current to swing wildly. Consider a high speed design > that uses clock enables to conserve power. That could bang-bang > in a big way. Either the regulator has to track the usage or > you have to have a big pile of caps to do the work. Have a look at digital.burned-fuses.de -- MfG FalkArticle: 43044
Hi, Although I use the 7000s and 3000s devices trouble less... I'm still trying to find a way to use the old altera 7000 devices (the non JTAG devices... I mean), as I do have some stock and for the low-end applications they are just fine. I've tried to find out the information on how to program these, and altera don't give the programming info (only sells the programming hardware), and it seems that nobody out there knows how ! I've tried to find a cheap (2nd hand) programmers (ebay and etc) but no luck. All the MPU stuff that shows up never have the PC card... And never find any third party programmer available... Programming info? or a low cost 2nd hand programmer? Any help out there ! Many Thanks. LuisC cupido@mail.ua.ptArticle: 43045
hello all
i would like to know regarding this
suppose i have a synchronous design A and design B.
if i want to synchronise both the designs,
and also do so,and synthesize the whole design,
then how will the setup and hold times violations
be adjusted and the maximum clock speed will be obtained for
the fpga? will they be actually taken care of by the software..?
can any help me.please write in detail...
thank u
prasad
Article: 43046Have not actually seen a working model but check out an off the shelf Realtec RTL8029. The 8019 has an ISA interface and the 8029 a PCI interface . Apparently it is also very cheap ( << cost of an FPGA). I do not know if you still have to provide PCI interface yourself. Victor Schutte "Shane Mulligan" <mememeiii@hotmail.com> wrote in message news:c25fdd8.0205090442.50ba0b4@posting.google.com... > I need some help, I'm designing and coding a PCI Ethernet adapter using > the verilog language. Its something I want to do as a personel project > and its not work related so I can't get any help there. > > The adapter will comply with PCI rev 2.2 and 802.3 standards. I have > looked at both specs but they as you can expect neither spec make no > reference to interfacing to the other. > > I have run into a few problems. > 1) I need to know what happens when the ethernet card receives packets > from another ethernet station? How is the data transfered to the CPU or > Memory? I don't know if I need both a Master and a Target PCI state machine. > All I know is that I think there are only two possible ways this can be > achieved. > > a) See I'm trying to figure out if I need a master state machine in the PCI > interface to initiate the transaction i.e. it would request the bus and > perform a merory write. > > or > > b) The ethernet adapther receives the packet and notifies the pci core. > The PCI core then aserts its INTC to the Interupt router would then assert > its IRQ to the CPU. The CPU then initiates and interrupt acknowlegedment > and the interrupt router then forwards an interruot vector fot the PCI > card. This informs the CPU of the ISR (Interupt service routine) and it > then initiates a read to the ethernet card. In this case the adapter > card only needs to have a target state machine. > > Here's were I need help. Your responce is appreciated...... > > Shane Mulligan.Article: 43047
<http://www.xilinx.com/xapp/xapp200.pdf> I just now noticed that you were looking for a DDR SRAM controller, not a DDR SDRAM controller. The useful part in the app note (IIRC) is how to use the clock as a net, and how to register the DDR data. Controlling an SRAM is no big deal once you get past the above. HTH On 8 May 2002 23:19:10 -0700, eyals@hywire.com (Eyal Shachrai) wrote: >spam , can you please refer me to this reference design ( their number >will be fine ) . the only two reference designs that can be related to >DDR SRAM , that I've found are : QDR SRAM controller and DDR SDRAM >controller. > >thanks , > Eyal > > >spam_hater_7@email.com (Spam Hater) wrote in message news:<3cd933cf.3018963@64.164.98.7>... >> Xilinx has two DDR reference designs available for free. >> >> And (almost) worth every penny. >> >> >> >> On 8 May 2002 00:45:00 -0700, eyals@hywire.com (Eyal Shachrai) wrote: >> >> >Hi , >> > >> >I'm working on a project which involves a xilinx's virtex-ii fpga. >> >the core of this fpga will run with a 125 MHz clock and interface with >> >a 250 MHz data rate DDR SRAM. >> >I would like to know whether xilinx have a reference design of a DDR >> >SRAM controller. and if not , would it be smart to use the QDR >> >referance design (xapp 262) with some modifications , as a DDR >> >controller? >> > >> >Thanks >> > Eyal.Article: 43048
H.L <alphaboran@yahoo.no-spam.com> wrote:
> <hamish@cloud.net.au> wrote in message
> news:3cd92e0f$0$15472$afc38c87@news.optusnet.com.au...
>> > AJ11 is a IO pin in the Virtex-E I use.
>> Does it have a differential name like IO_VREF_L122N_YY?
> No in the datasheet AJ11's description is just IO
Are you trying to use it as a differential pin or not?
I don't understand.
> Hmm, yes you are right.Thank you, I looked in the datasheet again and says
> that if you want a LVDS output you must instantiate a LVDS OBUF and then
> pass the signal from the P side and its inverted one from the N side of the
> pin. I have about 30 outputs in my FPGA (2 buses and some control signals),
> do I have to port map these signals in my code one by one ?
You can use a bus in your port to minimise the work.
entity my_top_level is
port (
bus_p: out std_logic_vector(7 downto 0);
bus_n: out std_logic_vector(7 downto 0);
...
);
end entity;
architecture struct of my_top_level is
signal bus: std_logic_vector(7 downto 0);
begin
lvds_buffers: for n in bus'range generate
-- I can't remember the component name or the port names
-- but you can find those in the libraries guide
lvds_buffer: obuf_lvds
port map (
i => bus(n),
o => bus_p(n),
ob => bus_n(n)
);
end generate;
end;
And (I think) you need to constrain both the bus_p[*] and bus_n[*]
signals in your UCF.
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
Article: 43049Thanks to Hal, Kevin, Stephen, and Steve for their very helpful replies. I have a much better understanding of what's going on now and what to do next. A couple more questions: Should the memcpy() routine for accessing pci memory space? We don't seem to be able to get it to work on an x86 linux box. Anyone have experience with compact PCI? Can a typical cPCI single board computer do a burst read? What are the most common PCI chip sets and their capabilities? Is there a good reference for this? More info about what I'm up to is available at: http://dustbunny.physics.indiana.edu/~paul/hallDrd The PCI card is a single channel prototype for a ~20K channel system. I'm considering cPCI/PXI for packaging. Another possibility is an embedded CPU on each card. Bus mastering is possible with the Xilinx core. I'm not sure I have enough resources left in the current XC2S50, but could use a larger part on a future version. Still, burst reads would result in a simpler overall system. Suggestions & comments appreciated. Paul
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