Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
I have declared a state in VHDL like this: type state_type is ( state1, state2, state3, state4, state5, state6, state7, state8); signal state: state_type := idle; and used it like this: test_process: process(clock, reset) begin if rising_edge(clock) then case state is when state1 => inverter_test <= not inverter_test; state <= state2; when state2 => inverter_test <= not inverter_test; state <= state3; ... end case; end process; but it doesn't work on Cyclone II, looks like it doesn't enter any WHEN block. But when I use only 3 states (state1...state3) instead of 8, it works. I've tried to enhance it with asynchronous reset and resetting the state to state1 on reset, and another try was synchronous reset. And I've tried to switch the state machine generation from "auto" to other settings etc., but no luck. "clock" is the output of a PLL (with 25 MHz input) and is 50 MHz. The timing report doesn't say that something is not met (at least for this entity). No warning for this entity. Another strange thing: I've used similiar states, with 8 or more different states, in other entities in the same project and it works, looks like it just doesn't work in this combination, so I can't post the whole project (because it contains about a dozen entities with IP of the company for which I'm working, the Cyclone is about 20% full). But the content of the WHEN blocks can even be as easy as inverting a signal and it doesn't work. As a workaround I've encoded the states with constant bit vectors, which works, but I'm frustrated that I have to use such workarounds and I'm frustrated that I needed too much time to find this bug, because I've searched it in my code, first, because usually it's not the tools fault, until I wrote the small test case above, which seems to verify my assumption that it is a bug in Quartus. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 112201
Al wrote: > Hi to everyone, > I'm developing some electronics to make a time measurement with a > resolution of 25 ps. I'm using a dedicated ASIC to do so but I'm giving > the signals to the ASIC through an FPGA. > The way is very simple, basically I have some signals coming to my fpga > which I will mask with some combinatorial logic and a configurable > register so that I can allow some measurements or some others. The > output of this "masking" will go to the ASIC. > They assert (and here is the question) that a clocked device as an FPGA > may add some jitter to the signals due to the substrate current > overload (for the presence of the clock) that will lead to some 15 ps > jitter over the signals. I don't know how they could resolve this value > but I'm assuming they were telling the truth about numbers (at least, > while I have some doubts about explanation of those numbers). > Can anyone say something about this? Does it sound reasonable? > > Al > For time measurements of this order, you'll need a *very* stable and low jitter clock source. I would suggest a PECL differential, or even perhaps a truly stabilised (thermally) oscillator. There's an old saw that the measuring equipment should be at least 5 times better than the measurement, so you're looking at 5ps of jitter in the _entire_ measurement system. If, however, you can live with 25ps of total jitter in the measurement system, then it may be do-able, but you are aiming for resolution in the order of 20GHz (assuming one edge to be captured is a half of a cycle). Keep in mind that you will have jitter introduced for: 1. Clock / signal input indeterminacy. At some point, you have to capture your signal. The FF will switch somewhere in the indeterminate region. The slower your input source, the worse this is. You can't expect a FF to switch at the same level two consecutive times either, although usually adjacent clocks will switch at a close level. Estimation of that jitter depends on the technology you are using. 2. Oscillator jitter. There will always be jitter on an oscillator. It might be low, but you can't get rid of it. 3. Possible metastability. This afflicts all FFs, and although it can be worked around, you should be aware of it. (It's not a high level issue, but it does exist - there was a thread on it recently) 4. PCB routing. All PCBs will exhibit deterministic jitter (which can be calculated). This will be made worse if you have vias on highspeed nets (which can be alleviated somewhat with differential techniques I won't go into here). Unless you are using waveguide or optical techniques (and even they suffer from jitter too) you'll have a low pass filter introducing jitter. Then there's track adjacency, impulse response of the power etc. Last, but not least, is impedance mismatch. There's always some, however small you may be able to get it. I have seen a single via add 50ps of deterministic jitter on fast signals (edge rate about 10^4V/us) on FR4-13. I have no idea what PCB material you are using or intend to use, but keep this in mind. Another issue of importance is which form of jitter is your biggest issue: Cycle to cycle? rms? peak to peak? long term (sometimes known as frequency drift) Some food for thought. Cheers PeteSArticle: 112202
Hello Frank, The problem you have referred to namely power up initialization and its interaction with state machine encloding has been fixed in Quartus II 6.0 SP1 which can be downloaded form teh Altera web site. Hope this helps, Subroto Datta Altera Corp. On Nov 17, 11:18 am, Frank Buss <f...@frank-buss.de> wrote: > I have declared a state in VHDL like this: > > type state_type is ( > state1, state2, state3, state4, state5, state6, state7, state8); > signal state: state_type := idle; > > and used it like this: > > test_process: process(clock, reset) > begin > if rising_edge(clock) then > case state is > when state1 => > inverter_test <= not inverter_test; > state <= state2; > when state2 => > inverter_test <= not inverter_test; > state <= state3; > ... > end case; > end process; > > but it doesn't work on Cyclone II, looks like it doesn't enter any WHEN > block. But when I use only 3 states (state1...state3) instead of 8, it > works. > > I've tried to enhance it with asynchronous reset and resetting the state to > state1 on reset, and another try was synchronous reset. And I've tried to > switch the state machine generation from "auto" to other settings etc., but > no luck. "clock" is the output of a PLL (with 25 MHz input) and is 50 MHz. > The timing report doesn't say that something is not met (at least for this > entity). No warning for this entity. > > Another strange thing: I've used similiar states, with 8 or more different > states, in other entities in the same project and it works, looks like it > just doesn't work in this combination, so I can't post the whole project > (because it contains about a dozen entities with IP of the company for > which I'm working, the Cyclone is about 20% full). But the content of the > WHEN blocks can even be as easy as inverting a signal and it doesn't work. > > As a workaround I've encoded the states with constant bit vectors, which > works, but I'm frustrated that I have to use such workarounds and I'm > frustrated that I needed too much time to find this bug, because I've > searched it in my code, first, because usually it's not the tools fault, > until I wrote the small test case above, which seems to verify my > assumption that it is a bug in Quartus. > > -- > Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.deArticle: 112203
not sure why, but it sounds like the Makefile in the
arch/ppc/platforms/xilinx_ocp directory didn't get regenerated after
you modified xilinx_syms.c
you could try making the modification to a virgin copy of the source
tree before running make menuconfig, make dep, etc... the Makefile
should look something like this:
---------------------
# Makefile for the Xilinx On Chip Peripheral support code
#
list-multi := xilinx_ocp.o
# Linux file to EXPORT_SYMBOL all of the Xilinx entries.
export-objs += xilinx_syms.o
xilinx_ocp-objs += xilinx_syms.o
# The Xilinx OS independent code.
xilinx_ocp-objs += xbasic_types.o xdma_channel.o
xdma_channel_sg.o \
xdmav3.o xdmav3_intr.o xdmav3_selftest.o
xdmav3_sg.o \
xipif_v1_23_b.o xpacket_fifo_v2_00_a.o \
xpacket_fifo_l_v2_00_a.o xversion.o
obj-$(CONFIG_XILINX_OCP) := xilinx_ocp.o
xilinx_ocp.o: $(xilinx_ocp-objs)
$(LD) -r -o $@ $(xilinx_ocp-objs)
include $(TOPDIR)/Rules.make
Peter Mendham wrote:
> funkrhythm wrote:
> > edit arch/ppc/platforms/xilinx_ocp/xilinx_syms.c
> > and change references to XpacketFifoV100a -> XpacketFifoV200a
> > (there's an include file and 4 EXPORT_SYMBOLs)
>
> Thanks for your reply, I tried what you said, I changed the lines:
> #include "xpacket_fifo_v1_00_b.h"
> EXPORT_SYMBOL(XPacketFifoV100b_Initialize);
> EXPORT_SYMBOL(XPacketFifoV100b_Read);
> EXPORT_SYMBOL(XPacketFifoV100b_SelfTest);
> EXPORT_SYMBOL(XPacketFifoV100b_Write);
> To read:
> #include "xpacket_fifo_v2_00_a.h"
> EXPORT_SYMBOL(XPacketFifoV200a_Initialize);
> EXPORT_SYMBOL(XPacketFifoV200a_Read);
> EXPORT_SYMBOL(XPacketFifoV200a_SelfTest);
> EXPORT_SYMBOL(XPacketFifoV200a_Write);
> I then did a make distclean, re-configured, did make dep then make
> bzImage. I got exactly the same errors: undefined references to the
> XPacketFifoV200a_* functions. I understand your fix, I just don't
> understand why it hasn't worked. Maybe I've done something wrong? If I
> look in arc/ppc/platforms/xilinx_ocp after the attempted build, there is
> a xpacket_fifo_v1_00_b.o but not a xpacket_fifo_v2_00_a.o, there is also
> a .xpacket_fifo_v1_00_b.o.flags but no equivalent v2 file. Any ideas?
>
> Thanks,
> -- Peter
Article: 112204Jon Elson wrote: > > > PeteS wrote: > >> >> I seem to recall from the distant past that the 8080 (some versions) >> used depletion load; i.e. a depletion mode device with gate tied to >> source instead of a resistive load. Not that it reduces the components >> (an in fact adds a pin per active transistor). >> > So do these depletion loads count in the 8000 transistors? Then, the > 8080 function could > maybe be performed by 4000 active devices and 4000 resistors. (Im sort > of thinking that > it was 8000 amplifying transistors in the count, 4000 just seems too > low, as you'd need > 2 for every FF, and the 8080 actually had a lot of registers, for the > time.) > > Jon > The depletion load devices did not count in the 'transistor' count - they were load devices - active resistors, really Cheers PeteSArticle: 112205
Hi Antti, are you using "Smart Compilation" ? Plain Quartus: If you have a design compiled with "Smart Compilation" enabled, and then change just a memory-content-file and restart compilation, a magic "MIF/HEX Updater" (or similar) appears after the Fitter-process (which is skipped by smart compilation) and does what you want. I suppose this is also doable on the command-line. But don't ask me about the NIOS-tool-flow, you know, I am using ERIC5 ;-) Thomas "Antti" <Antti.Lukats@xilant.com> schrieb im Newsbeitrag news:1163790539.029200.67630@f16g2000cwb.googlegroups.com... > kem...@yahoo.com schrieb: > >> On Nov 17, 6:50 am, "Antti" <Antti.Luk...@xilant.com> wrote: >> > I just cant belive it, its one of the most useful things for the FPGA >> > SoC designs, and its just not there? I really doesnt have time or fun >> > to reverse engineer the .SOF format only to be able write the data2sof >> > utility for Altera. >> >> Antti, >> >> Others have commented on the general-purpose case, but since you made a >> specfiic reference to processors its worth discussing the soft-CPU flow >> for placing your code/data into onchip ram. >> >> No, this wasn't forgotten. In fact, support for doing this has been >> around about as long as Nios I/Nios II have been (6+ years now?). There >> are even >> several ways to accomplish the task: >> >> - If you are building your Nios II software in the IDE, it will take >> any coce/data linked into >> an onchip memory peripheral and use the elf2hex command to create a hex >> initialization >> file. The onchip RAM RTL generated by SOPC Builder is written out to be >> initialized this >> way; if you compile your design w/o any software having been built, >> memory will be left >> un-initialized, while if you first compile your software and then >> (re)compile in quartus, >> the .hex file(s) are used to initialize the memories. >> >> If you turn on verbose command line output from the IDE (window -> >> preferences -> nios II), >> you'll see the precise commands fly by on the console for future >> reference and command- >> line use. >> >> - Although the IDE-based flow doesn't do this now, you can even update >> your .sof >> file very quickly with onchip ram contents without risk of triggering >> an entire >> re-compile. I cannot recall the exact syntax of the command but I >> believe the compilation >> step is the Quartus Assembler (quartus_asm) >> >> - The "small" example design that ships with Nios II uses the above >> IDE-based >> method to initialize onchip RAM and as I recall the design's readme and >> other >> literature discuss this. >> >> Note that there are exclusions to what I've said, specifically for the >> types of >> onchip ram (m-ram blocks in Stratix, Stratix II) that cannot be >> initialized until >> runtime. The wizard to create an onchip ram in SOPC Builder allows you >> to >> choose which type of ram block will be used, if you desire, to ensure >> that you >> can pre-initialize contents if that is what you need to do. >> >> Jesse Kempa >> Altera Corp. >> jkempa --at-- altera --dot-- com > > Dear Jesse, > > I know about all you said above. but you missed the point. > > in Xilinx flow you can run a tool like: > > data2mem system.bit software.elf download.bit > > it will take the FPGA design (with soft cpu) and merge the elf file > __into__ it. > > in Lattice flow you *can* do the same. > > in Altera flow this is ASFAIK __not_possible__ at all. > > What I need a very simple thing > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > my_design.sof + my_software.elf => my_ready_to_program.sof > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > I see no other way as doing full RE on the SOF to accomplish that. > its stupid, and I would REALLY like to use Altera tools to do that, > but if Altera is not able to provide such an important tool/option > then someone has todo it (I really would prefer to spend my time > with other things than doing RE on altera file formats) > > Antti >Article: 112206
Subroto Datta wrote: > The problem you have referred to namely power up initialization and > its interaction with state machine encloding has been fixed in Quartus > II 6.0 SP1 which can be downloaded form teh Altera web site. Thanks, I'll try it next week. I have encountered the problem in Quartus II 6 without service pack, so maybe SP1 will solve it and I can undo the manual encoding of the states. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 112207
Antti wrote: > Antti, It might be safer from a delay standpoint to use the slice flip-flops but using only the async R and S inputs, and tying the clock to ground. I'm not sure this will satisfy your need though, because that FF might be held reset during the part of start-up when you are intending to use it. Just thought I'd mention it as an alternative.Article: 112208
Thomas Entner schrieb: > Hi Antti, > > are you using "Smart Compilation" ? > > Plain Quartus: If you have a design compiled with "Smart Compilation" > enabled, and then change just a memory-content-file and restart compilation, > a magic "MIF/HEX Updater" (or similar) appears after the Fitter-process > (which is skipped by smart compilation) and does what you want. I suppose > this is also doable on the command-line. But don't ask me about the > NIOS-tool-flow, you know, I am using ERIC5 ;-) > > Thomas > Thomas, I dont want smart recompile! I want NO COMPILE. Compile once. Merge new ELF file into the SOF file n - times. AnttiArticle: 112209
Ray Andraka schrieb: > Antti wrote: > > > > > Antti, > > It might be safer from a delay standpoint to use the slice flip-flops > but using only the async R and S inputs, and tying the clock to ground. > I'm not sure this will satisfy your need though, because that FF might > be held reset during the part of start-up when you are intending to use > it. Just thought I'd mention it as an alternative. Thanks, - a good suggestion but it seems not useable. the S-R trick doesnt work either :( AnttiArticle: 112210
Ray Andraka schrieb: > Antti wrote: > > > > > Antti, > > It might be safer from a delay standpoint to use the slice flip-flops > but using only the async R and S inputs, and tying the clock to ground. > I'm not sure this will satisfy your need though, because that FF might > be held reset during the part of start-up when you are intending to use > it. Just thought I'd mention it as an alternative. uups - it may actually work, I had a test setup where I used SR flops but it also had someother things, and I did not build the divider out of SR flops, so I can retest the solution. SRL16 based divider doesnt work for sure that I checked. AnttiArticle: 112211
vasile wrote: > Hi everybody, > > A part of a project I'm designing is a PCMCIA bus card with a 32 bit > data system bus. > The system included in the card has a multicore DSP, an ARM processor, > some NOR FLASH, SDRAM memory and a FPGA. > The FPGA is used for the PCMCIA interface to the system bus and some > high speed math as a companion for DSP. The purpose of the whole PCMCIA > interface is to transfer some data from the SDRAM into PC, in real time > at 33Mhz clock rate. The card data system bus is running at 133MHz. > > How you'll chose the design for the best card bus interface, knowing > there are some fast processes on the internal bus: > > a. using the FPGA as a slave memory selected by the DSP and > implementing a FIFO inside the FPGA . An interrupt request will notice > the PC to start download data and empty the FIFO. > b. using DMA control over the system bus from the FPGA (FPGA as master, > DSP as slave) > c. other (please detail) > > thank you, > Vasile > There's a number of things you haven't mentioned (the actual data bandwidth?) although you say you need to transfer data at 33MHz - is that a continuous throughput rate? What else is connected to this memory bus? Many interfaces use the same bus lines as the main memory system. What controller is being used? How many clocks (minimum) per bus transaction? All these impact the choice of interface. The simplest is a simple memory device; much more complex is DMA access to a dual ported RAM. Which of those (or something in between) needs some numbers. Specific numbers: Throughput from FPGA (over time) Is the burst rate from the FPGA critical? (If so, it impacts the interface) Devices connected to the interface bus Bus type (specifies the bus cycle information) That would be a good start :) Cheers PeteSArticle: 112212
vasile wrote: > Hi everybody, > > A part of a project I'm designing is a PCMCIA bus card with a 32 bit > data system bus. > The system included in the card has a multicore DSP, an ARM processor, > some NOR FLASH, SDRAM memory and a FPGA. > The FPGA is used for the PCMCIA interface to the system bus and some > high speed math as a companion for DSP. The purpose of the whole PCMCIA > interface is to transfer some data from the SDRAM into PC, in real time > at 33Mhz clock rate. The card data system bus is running at 133MHz. > > How you'll chose the design for the best card bus interface, knowing > there are some fast processes on the internal bus: > > a. using the FPGA as a slave memory selected by the DSP and > implementing a FIFO inside the FPGA . An interrupt request will notice > the PC to start download data and empty the FIFO. When transferring data from the FPGA to or from PC system memory, implementing bus mastering within the FPGA will provide much higher data bandwidth. You don't want to use a slave interface for that purpose.Article: 112213
Jon Elson wrote: > PeteS wrote: > > > > > I seem to recall from the distant past that the 8080 (some versions) > > used depletion load; i.e. a depletion mode device with gate tied to > > source instead of a resistive load. Not that it reduces the components > > (an in fact adds a pin per active transistor). > > > So do these depletion loads count in the 8000 transistors? Then, the > 8080 function could > maybe be performed by 4000 active devices and 4000 resistors. (Im sort > of thinking that > it was 8000 amplifying transistors in the count, 4000 just seems too > low, as you'd need > 2 for every FF, and the 8080 actually had a lot of registers, for the time.) > > Jon Every transistor counts whether it is a logic pull down (enhancemenet) or load (depletion). or clocked pass gate or even any capacitors which are usually free in area, its always distinct mos gate area. A depletion transitor is usually used as a constant current source rather than resistor, but as a resistor if the gate has fixed voltage. Typically for all static logic I would expect 3 logic and 1 load device on avg, but in this case most logic was precharged and conditionally discharged. Only the register flops had to be static. Since it had a 12v supply, it may have not had any depletion device loads, using long thin enhacment t's s as loads, mucho area and power and poor speed. The 8085, Z80 definitely had depletion and hidden poly-diff contacts to simplify everthing. I did have the schematic for the datapath area and thats about 30% of the chip. IIRC maybe 8-10 registers included umdocumented, each was probably a 4t asymetric cross couple with an extra t to read and and t for write. An ALU bit slice is probably 20-30 t's so 1 datapath bitslice is probably <100 devices so <1000 for the whole math area.. Remember that t logic (see Mead Conway) can do alot for a few devices. 2e1d devices makes a 2 input nor or nand or poor mans xor and the ALU used only a few per bit. The carry was a precharged manchester pass gate with conditional discharge, the P,G terma probably reused a mux box function generator (a bit like a LUT) that also did the logic operations. Also the whole thing was state sequential, no pipelining so many cycles used to do trivial operations. The entire schematc could have easily been drawn on 1 large sheet of paper if need be. John Jakson transputer guyArticle: 112214
Andreas Ehliar wrote: > > If it turns up that your source code is too complicated to synthesize > with your current machine you could perhaps divide your design into > several files and compile each file separately. One keyword to search > for is incremental synthesis. > > > /Andreas Dear Andreas, Thanks for your reply to this post. I took the time to have a look at incremental synthesis (for XST) and it seems to be useful only if you have changed part of your design and want to save resynthesis time. As far as XST is concerned I am not so much concerned about the run time - than the Memory consumption. (I only have access to the 32 bit version so XST can use only 4GB of memory.) XST runs out of memory and then crashes - that's my problem. Regards, O.O.Article: 112215
Dear Thomas, Thanks for taking your time to reply. Thomas Stanka wrote: > > The number of gates _will_ increase, if you add gates! > I guess you even didn't care about signal buffering. A signal driving > 10k gates needs roughly 1000 gates for signal buffering. I found this comment useful - because I could not get this information in the manuals or other tutorials. (I never imagined so many gates would be required for buffering.) > node_16_cell_0 <= fault_4_node_16 when (insert_faults_cell_0 = > '1' and SEL_node_16_cell_0 = "01") else > fault_5_node_16 when > (insert_faults_cell_0 = '1' and SEL_node_16_cell_0 = "10") else > forg_node_16_cell_0; > > could be a bit smaller code replacement for your mux (won't change > anything concerning synthesis) but you drastically reduce the number of > lines for same functionality. Thanks for this code. I am dumping the VHDL using C++ - so actually I did not mind a few more output lines when I wrote it. Now that I am running into problems, I would have to go back and change it. > This code seems to introduce combinatorial paths with length of more > than 10k gates. > Don't do this. I guess even 100 gates per path will kill your tool. I did not understand this. Why would long combinatorial paths kill my tool (i.e. why is it difficult to synthesize - Routing Memory??) Do you (or anyone else reading this) have any suggestions for decreasing the combinatorial path length? > BTW: you do this for fault testing, right? Doubling your design to > achieve a fault coverage seems the wrong way for me > Yes you guessed right that this is related to fault testing. But I am not concerned about the concept (because it was my advisors) - my job is to try to implement it - whether it works or not. Thanks again for your help. O.O.Article: 112216
Even if you implement Cardbus (essentially PCI) rather than PCMCIA(essentially ISA) you won't get continuous 33MHz transfer other than short periods of time. ExpressCard format can go this fast providing the architecture behind it can support that data rate. John Adair Enterpoint Ltd. - Home of Tarfesock1. The Cardbus FPGA Development Board. vasile wrote: > Hi everybody, > > A part of a project I'm designing is a PCMCIA bus card with a 32 bit > data system bus. > The system included in the card has a multicore DSP, an ARM processor, > some NOR FLASH, SDRAM memory and a FPGA. > The FPGA is used for the PCMCIA interface to the system bus and some > high speed math as a companion for DSP. The purpose of the whole PCMCIA > interface is to transfer some data from the SDRAM into PC, in real time > at 33Mhz clock rate. The card data system bus is running at 133MHz. > > How you'll chose the design for the best card bus interface, knowing > there are some fast processes on the internal bus: > > a. using the FPGA as a slave memory selected by the DSP and > implementing a FIFO inside the FPGA . An interrupt request will notice > the PC to start download data and empty the FIFO. > b. using DMA control over the system bus from the FPGA (FPGA as master, > DSP as slave) > c. other (please detail) > > thank you, > VasileArticle: 112217
Antti wrote: > Thomas Entner schrieb: > > >>Hi Antti, >> >>are you using "Smart Compilation" ? >> >>Plain Quartus: If you have a design compiled with "Smart Compilation" >>enabled, and then change just a memory-content-file and restart compilation, >>a magic "MIF/HEX Updater" (or similar) appears after the Fitter-process >>(which is skipped by smart compilation) and does what you want. I suppose >>this is also doable on the command-line. But don't ask me about the >>NIOS-tool-flow, you know, I am using ERIC5 ;-) >> >>Thomas >> > > Thomas, > I dont want smart recompile! I want NO COMPILE. > > Compile once. > > Merge new ELF file into the SOF file n - times. I think Antti is after a solution that does not need Full Quratus, but is just a 'insert code' step. As he says, simple enough, and surprising it is not there aready. There must be many teams, where the software is separate from the FPGA development, and it is both quicker and safer to avoid any rebuild of the FPGA. Maintenance/version control, is another area where this ability gets important. Could you not find the portion of Quartus that Jesse mentioned ? Amongst the choices, he said: " you can even update your .sof file very quickly with onchip ram contents without risk of triggering an entire re-compile. I cannot recall the exact syntax of the command but I believe the compilation step is the Quartus Assembler (quartus_asm)" - and hopefully, that command line is both a small EXE, and not needing a license install :) -jgArticle: 112218
"Antti" <Antti.Lukats@xilant.com> schrieb im Newsbeitrag news:1163796133.373645.327180@m7g2000cwm.googlegroups.com... > Thomas Entner schrieb: > >> Hi Antti, >> >> are you using "Smart Compilation" ? >> >> Plain Quartus: If you have a design compiled with "Smart Compilation" >> enabled, and then change just a memory-content-file and restart >> compilation, >> a magic "MIF/HEX Updater" (or similar) appears after the Fitter-process >> (which is skipped by smart compilation) and does what you want. I suppose >> this is also doable on the command-line. But don't ask me about the >> NIOS-tool-flow, you know, I am using ERIC5 ;-) >> >> Thomas >> > Thomas, > I dont want smart recompile! I want NO COMPILE. > > Compile once. > > Merge new ELF file into the SOF file n - times. > > Antti > OK, I think I just realized what you are looking for (it's late...): precompiled bitstream you give to the user, where the user's custom firmware can be merged into... (I asume for your MicroFPGAs, originally I was thinking you just want to save compile-time). Don't know... With ERIC, I have the programm in a part of the configuration-SPI-Flash, as the internal RAM is quite small anyway. But I can see your point, as you have only the CPU in the FPGA... Maybe quartus_asm can help you in a way (as Jesse mentioned above), but I am afraid, it will rely on some contents of the db-subdirectory? ThomasArticle: 112219
On Nov 17, 6:52 am, "Antti" <Antti.Luk...@xilant.com> wrote:
> JustJohn schrieb:
>
>
>
>
>
> > John_H wrote:
> > > Antti wrote:
> > > > Hi
>
> > > > this may sound strange but I need flip flop or divide by 2 element that
> > > > is made purely out of combinatorical logic and passes fpga
> > > > implementation without being optimized away, and work in FPGA fabric. I
> > > > tried some D-flop code but it gets really optimized away and doesnt
> > > > work.
>
> > > > I wonder if someone has a solution for this. It really must be pure
> > > > logic, eg using DCM or BUFR is not ok, the solution must not use any
> > > > fabric flip flops or fabric clocked primitives at all.
>
> > > > Antti
>
> > > Sounds like you need a master/slave pair of latches (a DFF made out of
> > > gates). The only trouble would be convincing the tool to not optimize
> > > out or complain too harshly about the combinatorial loops.
>
> > > Two SR Latches chained together. The S and R inputs are the normal and
> > > inverted signal from the other stage (inverted between one pair) and the
> > > clock acts as a 3rd input - normal on one SR Latch, inverted on the
> > > other - to each NAND gate to make the latch transparent or to allow the
> > > latch.
>
> > > I'm thinking back to the old TI data book that mapped out all the simple
> > > TTL logic. Since you don't need asynchronous set/reset logic, you
> > > should need just the 4 LUTs.
>
> > Two LUTS/FF. Only one LUT required per latch, one for master latch, one
> > for slave, and . wiring, err routing, delays should be verified.
> > I'd list the init values, but haven't had my coffee yet this morning.
> > Just Johnhm, get your coffee and write it down :)
> and you get extra e-coffe from me.
>
> the non-LUT version of the master slave thing did not yield anyuseful
> result.
> sounds interesting to have a FF out of 2LUT (if it work also..)
>
> Antti- Hide quoted text -- Show quoted text -
(Not recommended for critical applications!)
Two 4-LUT divider, does not optimise away, sims ok too,
max clock is route dependent, you probably want to add RLOCs to force
the same slice for the LUTs, give Clock a chance to have close to
identical delays to both LUTs, if Clock delays are different, make sure
the Slave LUT is later.
You can toss the Reset term and instantiate LUT3s instead of LUT4s.
Let us know if it works for you...
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
library UNISIM;
use UNISIM.VComponents.all;
entity Antti_FF is
Port ( Clock : in STD_LOGIC;
Reset : in STD_LOGIC;
Div_2 : out STD_LOGIC);
end Antti_FF;
architecture Behavioral of Antti_FF is
signal Master : std_logic;
signal Slave : std_logic;
begin
Master_LUT: LUT4
-- Master LUT (First in the Master/Slave FF)
-- Holds Feedback when clock is high,
-- Passes Inverted Data when Clock is Low.
-- Reset available using 4-LUT, can be tied to 0
-- R=Reset D=Data C=Clock F=Feedback O=Output
-- R: 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
-- C: 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0
-- D: 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0
-- F: 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
-- O: 0 0 0 0 0 0 0 0 1 0 1 0 0 0 1 1
generic map ( INIT => x"00A3" )
port map (
O => Master,
I0 => Master,
I1 => Slave,
I2 => Clock,
I3 => Reset );
Slave_LUT: LUT4
-- Slave LUT inverts Clock sense,
-- Passes Data when Clock is High,
-- Passes Feedback when clock is low
-- R: 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
-- C: 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0
-- D: 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0
-- F: 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
-- O: 0 0 0 0 0 0 0 0 1 1 0 0 1 0 1 0
generic map ( INIT => x"00CA" )
port map (
O => Slave,
I0 => Slave,
I1 => Master,
I2 => Clock,
I3 => Reset );
Div_2 <= Slave;
end Behavioral;
Article: 112220I am design for an asic.prototyping a fpga I have four design file with 12 similar functional channels.Performance was good.Now i added 5th module to the design.3 channels working wrong .They are not functioning well.Is there any procedure to import constraints from previous version in altera quartusII s/w .How to do it. Please help me.Thanking you kumarArticle: 112221
kumar wrote: > I am design for an asic.prototyping a fpga > I have four design file with 12 similar functional channels.Performance > was good.Now i added 5th module to the design.3 channels working wrong > .They are not functioning well.Is there any procedure to import > constraints from previous version in altera quartusII s/w .How to do > it. > Please help me.Thanking you > kumar I am using quartus 6.0 web edition and EP2c20q240c8Article: 112222
Tell me from which university and departmant you are, and also your name, then I can answer your question. Of course for free ;-) Student (confused) schrieb: > Hello, > > Can someone point me to simple implementation of FFT in VHDL(or > Verilog) with testbench and good step-by-step description. I have > implementation from Xilinx (which I will eventually use for hardware > implementation), but I find it rather confusing (lack of vhdl > experience). Algorithm used, # of points, Radix#, bit precision do not > matter, as I'm looking for tutorial-like implementation. > The best example of what I'm looking for is (found using google) > http://www.opencores.org/projects.cgi/web/cf_fft/overview > http://www.opencores.org/cvsweb.shtml/fft/ > > Thanks.Article: 112223
Jeff, I went down this path about 9 months ago. The IBM core connect specification is definitely 64-bits wide AND it does allow for 32-bit bus implementations. However, to do so, requires targets to respond in correct word-lanes. Unfortunately the bridges implemented by Xilinx do not allow this to happen. At one time I found an application note at Xilinx that said the reason this was done was so that they could just implement a wired-data bus between all slaves/masters. By that, I mean to say that all slaves drive an answer back for every cycle and if any slave bits are 1 it gets passed that way to the core. I actually verified that the core signals allowing for non-64-bit operation are hardcoded by digging through all of the EDK VHDL source code for the PLB and OPB bridges. I actually made a custom version of the PLB bridge that allowed for 32-bit operation (I couldn't take the latency through the bridge) ... unfortunately since the bits of the busses could not be wired together, the routing got to be unruly very quickly. In the end, I decided the best approach was to attach 32-bit and less interface to the OPB and 64-bit busses to the PLB. Where I needed speed, I used a PLB slave and wasted the extra bits. Trevor "Jeff Cunningham" <jcc@sover.net> wrote in message news:455927fd$0$5782$4d3efbfe@news.sover.net... > Antti wrote: > >> >> PPC405 hard macro PLB DBUS *IS* 64 bits >> > > But according to the documentation, the native hard PLB interfaces on the > PPC core can be configured to operate in 32 bit mode, and they will adapt > themselves to just use 32 bits (i.e. you don't need any external 64 to 32 > bit mux). For instance, see the PLBC405DCUSSIZE1 parameter in the Power PC > 405 Processor Block Reference Guide. > > -JeffArticle: 112224
"Austin Lesea" <austin@xilinx.com> wrote in message news:ejkus8$kkk1@cnn.xsj.xilinx.com... > >> So, that's a cool thing. Did you guys do any measurements on the jitter >> performance of this? I.e. how much jitter is added to a differential data >> signal coming out of an IOB clocked by a BUFIO driven from a differential >> clock coming to the FPGA 'Clock Capable' pins.? > > Yes, we have performed a great deal of characterization. And the clock > capable pins, or even a plain IOB has no real difference in jitter > performance. > Hi Austin, Thanks for getting back! Your reply surprised me; I now wonder just what does the diff clock routing bring to the party if not better jitter performance? BTW, are the regular global clock networks differential? Thanks, Syms.
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