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
On Feb 25, 4:08=A0pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > >I know that MB is big-endian, vs my linux box being little-endian. > >But shouldn't the C compiler produce the same results, regardless > >of the system endianness ? > > Which one is right? > > If the compiler could do the "right" thing, we wouldn't have > endian wars. Well, clearly the "right thing", imho, would be to be consistent. rudiArticle: 138501
Thanks!!!I was confused with the division part of demodulation algorithm you mentioned.But it's true i think that the amplitude of I^2+Q^2 is always a constant due to the thing that I and Q have a difference in phase of π, so like the common expression cos(f)^2+sin(f)^2=1 the amplitude of I^2+Q^2 must be a constant. -- xristos ------------------------------------------------------------------------ xristos's Profile: http://www.fpgacentral.com/group/member.php?userid=15 View this thread: http://www.fpgacentral.com/group/showthread.php?t=88112Article: 138502
On Wed, 25 Feb 2009 03:00:23 -0800 (PST), luudee <rudolf.usselmann@gmail.com> wrote: >On Feb 25, 4:08 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal >Murray) wrote: >> >I know that MB is big-endian, vs my linux box being little-endian. >> >But shouldn't the C compiler produce the same results, regardless >> >of the system endianness ? >> >> Which one is right? >> >> If the compiler could do the "right" thing, we wouldn't have >> endian wars. > >Well, clearly the "right thing", imho, would be to be consistent. I think you'd need a better language than C for that. Ada's representation clauses come to mind - YOU define the data layout, exactly as the hardware does it. But porting Gnat to microblaze is probably non-trivial. (There is supposedly a PPC port, but I haven't heard of anyone using it with EDK) Meanwhile, faking it with shifts and masks is likely to be the best bet for portablility. - BrianArticle: 138503
DHPC, a leader in military sensor technology development, has openings for experienced software/hardware developers in several applications. The ideal candidate will have 3+ years experience in systems level programming using VHDL and FPGA in a DSP environment, using the ISE Project Navigator environment on Xilinx Virtex chipset. Programming with C/C++ using Code Composer, UNIX, Dos, and Windows experience is also desirable. Shell scripting is a plus. In addition any experience with real time programming environments, FIFO/LIFO queuing theory, and discrete memory allocation issues are a plus. The positions will challenge the programmers ability to creatively problem solve and implement designed algorithms. This is a full time position. All candidates must be US citizens and capable of getting government security clearance (read: no police record) Please forward resumes to: jleslie@dhpconsultants.comArticle: 138504
Hello I have a new virtex 5 design with a lot of IO going at the same speed. I've been told to put all this IO on the same column. Also I can then use the DCI bank cascading. Does anyone know the logic behind the bank numbering? I can't find any data on which banks are in which column. ColinArticle: 138505
Hi, When I was generating my code, I didn't know what exact Xilinx chip may be used so that I selected Virtex V chip as my target one time. During the development, I might have tried to generate libraries with Virtex II chips because I have many Virtex II libraries ready to use. It led to the situation that I really don't know which library belongs to which chip. For simulations, it doesn't matter. But now I am trying to implement my design on Virtex II chip, the problem comes clear: if all libraries used in my simulation are for Virtex II? I can't answer the question. So I would like to ask if Xilinx IST can automatically detect an error when a Virtex V chip library is used for a Virtex II chip project. I think it is. But to reduce risks of errors, I would like to ask experienced persons for a positive answer without any guess. Thank you. WengArticle: 138506
On Feb 25, 9:05 am, Weng Tianxiang <wtx...@gmail.com> wrote: > Hi, > When I was generating my code, I didn't know what exact Xilinx chip > may be used so that I selected Virtex V chip as my target one time. > During the development, I might have tried to generate libraries with > Virtex II chips because I have many Virtex II libraries ready to use. > It led to the situation that I really don't know which library belongs > to which chip. For simulations, it doesn't matter. But now I am trying > to implement my design on Virtex II chip, the problem comes clear: if > all libraries used in my simulation are for Virtex II? I can't answer > the question. > > So I would like to ask if Xilinx IST can automatically detect an error > when a Virtex V chip library is used for a Virtex II chip project. I > think it is. But to reduce risks of errors, I would like to ask > experienced persons for a positive answer without any guess. > > Thank you. > > Weng Simulation libraries and Synthesis libraries are different. XST does check synthesis libraries. PAR will fail if the wrong libraries are linked. ALArticle: 138507
On Feb 25, 4:49 am, Allan Herriman <allanherri...@hotmail.com> wrote: > rickman <gnu...@gmail.com> wrote innews:3774b465-11f4-4daa-aee7-d44f72fce9a6@n20g2000vba.googlegroups.com: > > > > > On Feb 24, 8:27 am, Allan Herriman <allanherri...@hotmail.com> wrote: > >> "Krzysztof Kepa" <nospam_blond...@poczta.fm> wrote > >> innews:go0pr0$6jj$1@ai > > oe.org: > > >> > "Allan Herriman" <allanherri...@hotmail.com> wrote in message > >> >news:Xns9BBCD0C44FABBallanherrimanhotmail@216.151.153.43... > >> >> Hi, > > >> >> I guess my questions are: > > >> >> 2. Will future generations FPGAs be able to be programmed via > >> >> PCIe? If so, when? > > >> > Now? ;) Just need to use some external components to tie it > >> > together...or use partial reconfiguration (PR) flow. > > >> I meant "gluelessly". With PR, one must get the original > >> configuration into the FPGA somehow, and (as I understand it) that > >> cannot be done with PCIe. > > >> Thanks for your comments. > > >> Allan > > > I haven't looked at processors like the Atom in a while, but I seem to > > recall that you get some number of general purpose I/O pins on most > > any processor. You only need four pins to completely control an FPGA > > configuration; PRGM, CCLK, DONE, INIT. They can be bit banged in > > software. The FPGA interface is not used very much when considered in > > the grand scheme of things. So I expect you will never see direct > > support for it on processors. > > > I also doubt that you will see dedicated support for PCIe in FPGAs. > > This is a bit lofty for a configuration interface. PCIe is point to > > point (right?) and taking one of the two PCIe interfaces on an Atom > > for booting the FPGA would be a bit of overkill. There are few > > applications where a processor like the Atom is used and you can't > > wait the few milliseconds for the FPGA to boot serially. > > That PCIe isn't wasted; it is needed for FPGA <-> cpu comms after > configuration. In your case that may be useful. My point is that in the general case this is not something that would be widely useful since PCIe ports are a very "expensive" way to configure a part when all you really need is four GPIO pins on the host. > I was actually thinking of applications without the chance of using GPIO > lines, e.g. on a PCIe plugin card. I don't know PCIe much, but I have worked with PCI before and I don't think it is practical to use an FPGA to provide the PCI interface. This issue may have been resolved at some point, but I want to say that an FPGA does not boot fast enough to respond to the initial enumeration comms on the bus. Has this issue been addressed so that an FPGA can boot from an on board PROM and provide a PCIe interface? > It still seems that the PCIe to local bus bridge is the best solution for > my hypothetical problem. The other suggestions involved Flash memories > (with an implied extra step during manufacturing to program the dang > things, not to mention the extra complexity involved with in-the-field > upgrades of that image) or a non-trivial amount of glue logic. I think the idea is that the image required to boot the FPGA enough to make it bootable over the PCIe interface would be pretty stable. So the concerns of needing to fix that would be a bit overblown. In fact, it is likely that you could design the interface to the boot Flash so that it can be programmed over the PCIe bus. Then, as long as the reprogramming did not go bust in the middle, you could update the Flash just like you load the rest of the image. Of course, the local bus interface still requires some extra logic to boot the FPGA, no? Or does the bridge chip provide signals that can be used directly? > I thought Glen's suggestion of loading the image into SRAM first was > neat, but probably not suitable for me. You don't really need to load the FPGA fresh on **every** boot do you? You could provide the Flash to boot from and only update it when you have changes. You could use a protected boot block to load the initial image. If an update is installed in the rest of the Flash, the initial image would then reboot the FPGA from that updated image. This gives you a guaranteed level of boot so that you never loose the ability to boot and can still support updates. The selection of whether to reboot from the secondary image could be put under software control. I've been working with a flash based FPGA which uses the Flash as a shadow of the configuration RAM. The part can be booted from the Flash or the RAM can be directly configured without disturbing the Flash for temporary boots. I think this provides some interesting boot and update possibilities when controlled by a host. RickArticle: 138508
On Feb 23, 4:49=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > On Feb 23, 12:42=A0pm, Dave Pollum <vze24...@verizon.net> wrote: > > > > > > > On Feb 23, 3:38=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > Hi, > > > It is intersting to find that $24.50 is for an Altera ByteBlast > > > programmer mentioned in a topics in FPGA group. > > > > I need to buy a programmer suitable for Xilinx Virtex II XC2V1500 chi= p > > > only. > > > > Please give any tips where I can buy a cheap programmer. > > > > Thank you. > > > > Weng > > > Digilent (digilentinc.com) has inexpensive programming cables. > > -Dave Pollum > > Hi Dave, > Good information! I need cables too. But hopefully I may get a set of > programmer plus its cables from one person or a company. > > Weng- Hide quoted text - > > - Show quoted text - Hi Dave, I checked Digilent.com website and I am not sure which one works for my system: Xilinx Virtext II XC2V 1000. JTAG Programming Cable $12.00 low-cost JTAG configuration solution for use with any JTAG-programmable device connects directly to the parallel port of a PC, and to a standard 6- pin JTAG programming header can program devices that have a JTAG voltage of 1.8V or greater I found my board has a 14-pin connector, but above specs says it has a 6-pin JTAG programming header. Is it fit? Is Xilinx iMPACT software still usable? Please give me a help to determine if which is fit. Thank you. WengArticle: 138509
On Feb 25, 9:30=A0am, LittleAlex <alex.lo...@email.com> wrote: > On Feb 25, 9:05 am, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > > > Hi, > > When I was generating my code, I didn't know what exact Xilinx chip > > may be used so that I selected Virtex V chip as my target one time. > > During the development, I might have tried to generate libraries with > > Virtex II chips because I have many Virtex II libraries ready to use. > > It led to the situation that I really don't know which library belongs > > to which chip. For simulations, it doesn't matter. But now I am trying > > to implement my design on Virtex II chip, the problem comes clear: if > > all libraries used in my simulation are for Virtex II? I can't answer > > the question. > > > So I would like to ask if Xilinx IST can automatically detect an error > > when a Virtex V chip library is used for a Virtex II chip project. I > > think it is. But to reduce risks of errors, I would like to ask > > experienced persons for a positive answer without any guess. > > > Thank you. > > > Weng > > Simulation libraries and Synthesis libraries are different. > > XST does check synthesis libraries. =A0PAR will fail if the wrong > libraries are linked. > > AL- Hide quoted text - > > - Show quoted text - Hi Al, Can I have a text editor software to find which type of chips a library belongs to? So that I don't have to wait for PAR error to happen. I remember *.edn files are libraried for synthesis. But I couldn't find any keyword about the chip in a *.edn file. WengArticle: 138510
In the general case, I and Q aren't normalized and cover a certain amplitude range. Some kind of normalization, e. g. dividing by I^2+Q^2, is required, if the decoder output has to be correctly scaled. Cause the carrier magnitude can be expected to vary only slowly, other means as an AGC can be used as well. This is the case with usual FM receivers.Has anyone an idea about implementation of an AGC for fm demodulator? -- xristos ------------------------------------------------------------------------ xristos's Profile: http://www.fpgacentral.com/group/member.php?userid=15 View this thread: http://www.fpgacentral.com/group/showthread.php?t=88112Article: 138511
>That PCIe isn't wasted; it is needed for FPGA <-> cpu comms after >configuration. >I was actually thinking of applications without the chance of using GPIO >lines, e.g. on a PCIe plugin card. This problem has been around for a long time. It also happens with PCI (no e). The fundamental problem is that you need a place to stand while you are programming the FPGA so it's tricky to get the FPGA to program itself before it has been programmed. In order to program a FPGA from a CPU, you need something like GPIO pins. Most modern compute CPUs (as compared to embedded CPUs) don't have any "extra" pins like that. The best approach I know of is to load the FPGA from the normal serial PROM and setup a few extra pins on the FPGA so that it can reprogram the PROM. It may require some glue. As long as you don't shoot yourself in the foot you can do that over and over. You probably die if you lose power in the middle of re-programming. I forget the vendor name, but somebody makes a set of PCI to xxx chips. They are often used to talk to FPGAs. They have a bus to transfer large clumps of data, and also several GPIO pins. I expect they do/will make a PCIe version. If that fits with your design, you could use one of them between your FPGA and the PCIe bus. You could wire up a few of the GPIO pins to program the FPGA. This is ugly in the sense that it requires another big expensive chip, but it might let you use a smaller FPGA since the bus interface can be simpler. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 138512
>I guess the bigger question here is how to correctly >interface a little endian peripheral to a big-endian >SoC ? It's a hard problem. It's been around for ages. >Byte swapping everything would mean that the user manual >for the pripoheral would have to be rewritten as well ... You may want byte swapping in the hardware. It depends on what you are talking to. If it's something like a disk or ethernet, where you often transfer text, you are probably better off treating it as a byte stream which means you will have to byte-swap (in software) to use things like 4 byte integers. Note that if you byte-swap the bus pins, that will byte swap addresses on a shared bus. So you may have to swap addresses in the driver so they will come out right when the hardware swaps them again. You can probably write a user manual that covers both cases. The trick is to write it using words and word addresses/offsets, then describe each word with pictures and bit offsets or terms like "high byte" rather than byte addresses. "Word" in that sentence means whatever the natural width of the bus is. Or you can just describe it for the normal/natural case and let the poor guy who is using it on the wrong-endian system sort things out. He should be familiar with the problem and know how to read wrong-endian data sheets. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 138513
Is there a way in VHDL to access the FSM encoding by the synthesis
tool as a std_logic_vector.
in other words: is there a tool supported way to convert my enumerated
state variable (eg: INIT, CLK_LOW, CLK_HIGH, etc) to a
std_logic_vector?
The only alternative I'm seeing is having my own process in the
format:
process(state)
begin
case state is
when INIT =>
out <= "000";
when CLK_LOW =>
out <= "001";
.
.
.
end case;
end process;
Thanks!
Article: 138514M. Hamed wrote: > Is there a way in VHDL to access the FSM encoding by the synthesis > tool as a std_logic_vector. > > in other words: is there a tool supported way to convert my enumerated > state variable (eg: INIT, CLK_LOW, CLK_HIGH, etc) to a > std_logic_vector? > > The only alternative I'm seeing is having my own process in the > format: > > process(state) > begin > case state is > when INIT => > out <= "000"; > when CLK_LOW => > out <= "001"; > . > . > . > end case; > end process; I don't think there is a portable way to access the std_logic_vector of a state machine, because a synthesizer is not required to synthesize it as a bit vector at all. They can optimize it away, using gray codes etc. Why do you need to translate your state to a number? -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 138515
For debugging purposes. My FSM gets stuck somewhere and I wanted to be able to read the current state as a register. On Feb 25, 2:15=A0pm, Frank Buss <f...@frank-buss.de> wrote: > M. Hamed wrote: > > Is there a way in VHDL to access the FSM encoding by the synthesis > > tool as a std_logic_vector. > > > in other words: is there a tool supported way to convert my enumerated > > state variable (eg: INIT, CLK_LOW, CLK_HIGH, etc) to a > > std_logic_vector? > > > The only alternative I'm seeing is having my own process in the > > format: > > > process(state) > > begin > > =A0 =A0case state is > > =A0 =A0 =A0 when INIT =3D> > > =A0 =A0 =A0 =A0 =A0out <=3D "000"; > > =A0 =A0 =A0when CLK_LOW =3D> > > =A0 =A0 =A0 =A0 =A0out <=3D "001"; > > =A0 =A0 =A0. > > =A0 =A0 =A0. > > =A0 =A0 =A0. > > =A0 =A0end case; > > end process; > > I don't think there is a portable way to access the std_logic_vector of a > state machine, because a synthesizer is not required to synthesize it as = a > bit vector at all. They can optimize it away, using gray codes etc. > > Why do you need to translate your state to a number? > > -- > Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-sys= tems.deArticle: 138516
On Feb 25, 9:51=A0am, colin <colin_toog...@yahoo.com> wrote: > Hello > > I have a new virtex 5 design with a lot of IO going at the same speed. > I've been told to put all this IO on the same column. Also I can then > use the DCI bank cascading. > > Does anyone know the logic behind the bank numbering? I can't find any > data on which banks are in which column. > > Colin You really need to dig for this information. I was told to use "ADEPT" to get a picture of the columns. There is a long thread on the Xilinx forums about this. http://forums.xilinx.com/xlnx/board/message?board.id=3DVirtex&thread.id=3D9= 1&view=3Dby_date_ascending&page=3D1 Regards, GaborArticle: 138517
mhelshou@hotmail.com wrote: > For debugging purposes. My FSM gets stuck somewhere and I wanted to be > able to read the current state as a register. So you have some real hardware and maybe an embedded CPU, which can read the state? Did you try to write a testbench in a simulator? The integrated simulator in Quartus is crap, but the free ModelSim version for Quartus is nice and you can see it in a timing diagram, with the names of the states instead of numbers, setting breakpoints etc. The integrated simulator in Xilinx ISE is usable, too. First you should reproduce the problem with a testbench, because this helps later for regression testing, if you change your entity. For your statemachine problem: Once I had a similar problem: The statemachine justs stops on real hardware from time to time, but it was impossible from the VHDL code. The bug was, that I didn't latched the (asynchronous) input signals. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 138518
My Name wrote: > In the general case, I and Q aren't normalized and cover a certain > amplitude range. Some kind of normalization, e. g. dividing by I^2+Q^2, > is required, if the decoder output has to be correctly scaled. Cause the > carrier magnitude can be expected to vary only slowly, other means as an > AGC can be used as well. This is the case with usual FM receivers.Has > anyone an idea about implementation of an AGC for fm demodulator? > > You do not need it. You are measuring angles not amplitude.Article: 138519
rickman <gnuarm@gmail.com> wrote in news:9e5e3729-4da1-41b4-9ec2-9c8f5dfe24d6@r36g2000vbp.googlegroups.com: > On Feb 25, 4:49 am, Allan Herriman <allanherri...@hotmail.com> wrote: >> rickman <gnu...@gmail.com> wrote >> innews:3774b465-11f4-4daa-aee7-d44f72fce9a6@n20g2000vba.googlegroups.c >> om: >> >> >> >> > On Feb 24, 8:27 am, Allan Herriman <allanherri...@hotmail.com> >> > wrote: >> >> "Krzysztof Kepa" <nospam_blond...@poczta.fm> wrote >> >> innews:go0pr0$6jj$1@ai >> > oe.org: >> >> >> > "Allan Herriman" <allanherri...@hotmail.com> wrote in message >> >> >news:Xns9BBCD0C44FABBallanherrimanhotmail@216.151.153.43... >> >> >> Hi, >> >> >> >> I guess my questions are: >> >> >> >> 2. Will future generations FPGAs be able to be programmed via >> >> >> PCIe? If so, when? >> >> >> > Now? ;) Just need to use some external components to tie it >> >> > together...or use partial reconfiguration (PR) flow. >> >> >> I meant "gluelessly". With PR, one must get the original >> >> configuration into the FPGA somehow, and (as I understand it) that >> >> cannot be done with PCIe. >> >> >> Thanks for your comments. >> >> >> Allan >> >> > I haven't looked at processors like the Atom in a while, but I seem >> > to recall that you get some number of general purpose I/O pins on >> > most any processor. You only need four pins to completely control >> > an FPGA configuration; PRGM, CCLK, DONE, INIT. They can be bit >> > banged in software. The FPGA interface is not used very much when >> > considered in the grand scheme of things. So I expect you will >> > never see direct support for it on processors. >> >> > I also doubt that you will see dedicated support for PCIe in FPGAs. >> > This is a bit lofty for a configuration interface. PCIe is point >> > to point (right?) and taking one of the two PCIe interfaces on an >> > Atom for booting the FPGA would be a bit of overkill. There are >> > few applications where a processor like the Atom is used and you >> > can't wait the few milliseconds for the FPGA to boot serially. >> >> That PCIe isn't wasted; it is needed for FPGA <-> cpu comms after >> configuration. > > In your case that may be useful. My point is that in the general case > this is not something that would be widely useful since PCIe ports are > a very "expensive" way to configure a part when all you really need is > four GPIO pins on the host. > > >> I was actually thinking of applications without the chance of using >> GPIO lines, e.g. on a PCIe plugin card. > > I don't know PCIe much, but I have worked with PCI before and I don't > think it is practical to use an FPGA to provide the PCI interface. > This issue may have been resolved at some point, but I want to say > that an FPGA does not boot fast enough to respond to the initial > enumeration comms on the bus. Has this issue been addressed so that > an FPGA can boot from an on board PROM and provide a PCIe interface? > > >> It still seems that the PCIe to local bus bridge is the best solution >> for my hypothetical problem. The other suggestions involved Flash >> memories (with an implied extra step during manufacturing to program >> the dang things, not to mention the extra complexity involved with >> in-the-field upgrades of that image) or a non-trivial amount of glue >> logic. > > I think the idea is that the image required to boot the FPGA enough to > make it bootable over the PCIe interface would be pretty stable. So > the concerns of needing to fix that would be a bit overblown. In > fact, it is likely that you could design the interface to the boot > Flash so that it can be programmed over the PCIe bus. Then, as long > as the reprogramming did not go bust in the middle, you could update > the Flash just like you load the rest of the image. > > Of course, the local bus interface still requires some extra logic to > boot the FPGA, no? Or does the bridge chip provide signals that can > be used directly? They usually have a few GPIO lines as well as a parallel data bus. This allows some sort of slave parallel mode to be used without glue logic. Just in case you are interested, here are some typical parts: 1 Lane: http://www.plxtech.com/products/expresslane/pex8311.asp 4 Lanes with dedicated FPGA loading support: http://www.gennum.com/video/products/gn4124 Here's the article that inspired this thread: http://www.pldesignline.com/howto/210300269 Regards, AllanArticle: 138520
hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote in news:ddadncju0b08ODjUnZ2dnUVZ_qvinZ2d@megapath.net: > I forget the vendor name, but somebody makes a set of PCI to xxx > chips. They are often used to talk to FPGAs. They have a bus > to transfer large clumps of data, and also several GPIO pins. > I expect they do/will make a PCIe version. > > If that fits with your design, you could use one of them > between your FPGA and the PCIe bus. You could wire up a few > of the GPIO pins to program the FPGA. > > This is ugly in the sense that it requires another big expensive > chip, but it might let you use a smaller FPGA since the bus > interface can be simpler. We've come full circle; what you wrote is what I was suggesting in my original post :) Here's what I said: "So far, it seems the best way is (despite the FPGA on-board transceivers) to use a PCIe to local bus bridge chip from PLX or Gennum." They're not so big an expensive compared with the other solutions I've been considering. The silicon costs a few dollars more, but I can eliminate the manufacturing step for programming a Flash. Regards, AllanArticle: 138521
> Thanks for the useful tips; it seems the primary approach is to "stretch" > the signals of interest into fast elements like shift registers and/or carry > chains, and then count these up at some leisure later (how?). That sounds > like it takes a lot of resources (e.g., 16 ticks per slice if I use a > SRL16E). This could explain why some of the papers I've glanced at seem to > take pretty much an entire chip to make a couple of these high-end delay > measuring devices. The highest precision ones capture a delay line, and then decode the edge position later, to decide how many delay elements were used. Of course, this also needs a calibrate action, so one method is to interleave two delay lines, one is doing a CAL whilst the other measures - you can use a lot of elements doing this, but they are cheap in a fpga. > For now, since it seems feasible to run a small (8 bit) > counter at 204.8 MHz, I'll try that route. 4.883 ns of precision is about > 1.5 meters when you multiply by c, so that's still useful to me. Once I get > the basic structure figured out I can look at speeding it up. Today I got > the input logic figured out (what signal is my start condition, and what is > my stop). Since I'm using these signals to calibrate out differences between > identical bitstreams on separated boards inside a common chassis, the > differential delays inside the logic should mostly wash out. Don't forget most FPGAs allow multiple phase clocks, so you can duplicate this 4 x on 4 phases, and compare the 4 answers -jgArticle: 138522
On Wed, 25 Feb 2009 10:05:04 -0800 (PST), rickman <gnuarm@gmail.com> wrote: >On Feb 25, 4:49 am, Allan Herriman <allanherri...@hotmail.com> wrote: >> rickman <gnu...@gmail.com> wrote innews:3774b465-11f4-4daa-aee7-d44f72fce9a6@n20g2000vba.googlegroups.com: > >I don't know PCIe much, but I have worked with PCI before and I don't >think it is practical to use an FPGA to provide the PCI interface. >This issue may have been resolved at some point, but I want to say >that an FPGA does not boot fast enough to respond to the initial >enumeration comms on the bus. Has this issue been addressed so that >an FPGA can boot from an on board PROM and provide a PCIe interface? Since PCI (at least in CompactPCI form) and PCIe theoretically support hotplugging, I don't see that this is a fundamental issue; it must be possible to rescan the PCI bus to detect and add devices that weren't awake (or even plugged in!) at boot time. Certainly on Linux there is a PCI Hotplug interface; I don't know how (or even if) it works in this role. But it suggests that the problem must have a solution. - BrianArticle: 138523
On Feb 25, 3:51=A0pm, "M. Hamed" <mhels...@hotmail.com> wrote: > Is there a way in VHDL to access the FSM encoding by the synthesis > tool as a std_logic_vector. > > in other words: is there a tool supported way to convert my enumerated > state variable (eg: INIT, CLK_LOW, CLK_HIGH, etc) to a > std_logic_vector? > > The only alternative I'm seeing is having my own process in the > format: > > process(state) > begin > =A0 =A0case state is > =A0 =A0 =A0 when INIT =3D> > =A0 =A0 =A0 =A0 =A0out <=3D "000"; > =A0 =A0 =A0when CLK_LOW =3D> > =A0 =A0 =A0 =A0 =A0out <=3D "001"; > =A0 =A0 =A0. > =A0 =A0 =A0. > =A0 =A0 =A0. > =A0 =A0end case; > end process; > > Thanks! Try this - it isn't guaranteed to be the same encoding as the synthesizer will use, but it will give you the state represented by a SLV: library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; type state_type is (IDLE, STATE1, STATE2, ...); signal state : state_type; signal state_slv : std_logic_vector(num_bits-1 downto 0); ... state_slv <=3D std_logic_vector(to_unsigned(state_type'pos(state), num_bits)); This should give you the state number, starting from zero and in the same order as they are declared the the type definition. DaveArticle: 138524
> <mhelshou@hotmail.com> wrote in message > news:3a9d2206-c1a6-420d-a9d6-6e6cb8b610e8@v15g2000yqn.googlegroups.com... > For debugging purposes. My FSM gets stuck somewhere and I wanted to be > able to read the current state as a register. Presumably the debug you're referring to is in hardware, not simulation since sim wouldn't require converting an enumerated type into a std_logic_vector for debug. That being the case, then you could peruse your synthesis log file it likely says how it is encoding the enumerated signal, there is likely a note to that effect. More to the point though, you'll need to bring that signal out to I/O pins so you'll need to be using whatever sort of 'signal probe' stuff that your tools support which means you'll be navigating down to the entity in question and then pulling out the synthesized signals. The other way to look at it, is that if you're certain that the FSM is 'stuck somewhere' and not something entirely unrelated then this likely implies that you have either an input to the state machine that is not synchronized to the clock, or simply that you're running the thing faster than you should be as defined by the timing analysis report. Usually a quick perusal checking the logic path of the inputs will turn up the source of unsynchronized input signals and an even quicker perusal of the timing report will uncover if you're trying to clock the design at too high of a clock rate. Kevin Jennings
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