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 May 20, 11:05=A0am, CMOS <manusha1...@gmail.com> wrote: > hi all, > im planning to implement barcode scanning using a CMOS sensor. The > processing needs to happen inside a FPGA, so im evaluating my options > in choosing a proper soft processor for the task. these are my > requirements. > > 1) open source and need to be able to be used in commercial products > 2) need to have good documentation and support tools (toolchain, > simulators, emulators) > 3) robust and stable > 4) need to use in an xilinx spartan 3 device with 400K gates. > > i know about processors OpenRISC 1000, NIOS 2 and LEON 2, but not sure > how good they are with regard to my requirements, specially the (2), > (3) and (4) above. Please help. > > in addition, i like to here about microblaze and its licensing fees > structure A few points: - Nios II and MicroBlaze aren't open source, but both are very good. - Is OpenRISC 1000 ok for commercial products? - I doubt LEON 2 (and maybe OpenRISC 1000) can fit in "400K gates" You could also consider YARI (http://yari.thorn.ws). It's a bit weak in the documentation department though but has great tools. The hardware debugger still work in progress, but YARI has excellent simulation support. Regards, TommyArticle: 140626
"MikeWhy" <boat042-nospam@yahoo.com> wrote in message news:odWQl.17139$%54.3159@nlpi070.nbdc.sbc.com... > "HT-Lab" <hans64@ht-lab.com> wrote in message > news:W7QQl.80572$861.55894@newsfe12.ams2... >> Does anybody know how to disable the CONV_INTEGER warnings in ISIM >> (11.1)? >> >> at 3000290500 ps(1), Instance /cpu_top_tb/U_12/ : Warning: CONV_INTEGER: >> There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, and it has been >> converted to 0. >> at 3000365500 ps(1), Instance /cpu_top_tb/U_12/ : Warning: CONV_INTEGER: >> There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, and it has been >> converted to 0. > > Only just guessing at the context... I would think ISIM's post-route > simulation elaborator is complaining that it's forcing to '0' an > uninitialized integer referenced in a math operation. > Hi Mike, Yes you are correct, these message are normally generated by Synopsys/IEEE packages and in Modelsim I just turn them off. I know what's causing them and fixed the issue by changing the code, however, it would be useful to have an option to turn them off. Hans, www.ht-lab.comArticle: 140627
"HT-Lab" <hans64@ht-lab.com> wrote in message news:51YQl.67411$M64.58819@newsfe26.ams2... > > "MikeWhy" <boat042-nospam@yahoo.com> wrote in message > news:odWQl.17139$%54.3159@nlpi070.nbdc.sbc.com... >> "HT-Lab" <hans64@ht-lab.com> wrote in message >> news:W7QQl.80572$861.55894@newsfe12.ams2... >>> Does anybody know how to disable the CONV_INTEGER warnings in ISIM >>> (11.1)? >>> >>> at 3000290500 ps(1), Instance /cpu_top_tb/U_12/ : Warning: CONV_INTEGER: >>> There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, and it has >>> been converted to 0. >>> at 3000365500 ps(1), Instance /cpu_top_tb/U_12/ : Warning: CONV_INTEGER: >>> There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, and it has >>> been converted to 0. >> >> Only just guessing at the context... I would think ISIM's post-route >> simulation elaborator is complaining that it's forcing to '0' an >> uninitialized integer referenced in a math operation. >> > Hi Mike, > > Yes you are correct, these message are normally generated by Synopsys/IEEE > packages and in Modelsim I just turn them off. I know what's causing them > and fixed the issue by changing the code, however, it would be useful to > have an option to turn them off. Hmmm. 'U' + 'X' is useful? ;) Selectively ignorable, yes, but habitually ignoring them silently does sound potentially problematic.Article: 140628
On May 20, 1:58=A0pm, VIPS <thevipulsi...@gmail.com> wrote: > On May 19, 2:39=A0pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> > wrote: > > > > > Dear Vipul, > > > Seems like you are always going to get > > some sort of timing issue since the rst > > signal and the SDA_IN signal are async. > > > Propagating the STARTOP signal forward > > to the STOPOP reset circuitry also seems > > like a bad idea for some reason I can't > > quite articulate, except for an idea that > > the start and stop signals should be > > symetrical. > > > If you have a system clock, I would suggest > > that you use registers at your SDA and SCL > > inputs right at the IOs. Then use old values > > of SDA and SCL to calculate your START and > > STOP signals: > > > start_stop_proc:process(clk) > > begin > > if(clk'event and clk=3D'1')then > > =A0 STARTOP<=3D'0'; > > =A0 STOPOP<=3D'0'; > > =A0 SDA_1<=3DSDA_IN; > > =A0 SDA_2<=3DSDA_1; > > =A0 SCL_1<=3DSCL_IN; > > =A0 if( SDA_1=3D'0' and SDA_2=3D'1' and SCL_1=3D'1')then > > =A0 =A0STARTOP<=3D'1'; > > =A0 end if; > > =A0 if( SDA_1=3D'1' and SDA_2=3D'0' and SCL_1=3D'1')then > > =A0 =A0STOPOP<=3D'1'; > > =A0 end if; > > end if; > > end process; > > > This should be very clean as long as your system clock > > and timing is OK. And it give clean oneshot reset signals > > for your address and data registers. > > > Now if you are trying to run this from the SCL clock, perhaps > > just taking the rst out of your process may work, or putting > > it in the synchonous part of the block may work, and clean > > up the code so that the both signals look symetrical: > > > start_proc:process(SDA_IN) > > begin > > =A0if(SDA_IN'event and SDA_IN=3D'0')then > > =A0 if(rst=3D'1')then > > =A0 =A0STARTOP<=3D'0'; > > =A0 elsif(scl=3D'1')then > > =A0 =A0STARTOP<=3D'1'; > > =A0 else > > =A0 =A0STARTOP<=3D'0'; > > =A0 end if; > > =A0end if; > > end process; > > > stop_proc:process(SDA_IN) > > begin > > =A0if(SDA_IN'event and SDA_IN=3D'1')then > > =A0 if(rst=3D'1')then > > =A0 =A0STOPOP<=3D'0'; > > =A0 elsif(scl=3D'1')then > > =A0 =A0STOPOP<=3D'1'; > > =A0 else > > =A0 =A0STOPOP<=3D'0'; > > =A0 end if; > > =A0end if; > > end process; > > > Then these signals need to be synched with scl clock > > signal before you start messing with your data registers. > > And you have to look for their edges since the SDA signal > > can drop and not come up if it's sending a zero datum. > > > Using a system clock is a lot easier. > > > I haven't ever done a I2C slave so you might get better > > answers elsewhere. Good luck. > > > Brad Smallridge > > AiVision > > > "VIPS" <thevipulsi...@gmail.com> wrote in message > > >news:35bbb41b-ce32-4cb6-868e-a459b10d05a7@s28g2000vbp.googlegroups.com..= . > > > > Hi all > > > > I am implementing the I2C Slave and I am using the I2C clock SCL for > > > detecting the start and stop condition . I am detecting the start and > > > stop successfully in simulation but i am not able to do the same in > > > the post synthesis scenario. More so I am getting a setup time > > > violation for the same in the timing analysis . I am running the I2C > > > at a very slow speed of 100KHz. > > > > The code is below > > > > process (SDA_IN, START_RST,rst) > > > =A0 begin > > > =A0 =A0 if rst =3D'1' then > > > =A0 =A0 =A0 =A0STARTOP <=3D'0'; > > > =A0 =A0-- elsif (START_RST =3D '1') then > > > =A0 =A0-- =A0 =A0STARTOP <=3D '0'; > > > =A0 =A0 elsif (SDA_IN'event and SDA_IN =3D '0') then > > > =A0 =A0 =A0 STARTOP <=3D scl; > > > =A0 =A0 end if; > > > =A0 end process; > > > ---------------------------------------------------------------------= --------- > > > -- stop condition detection > > > process (RST, SCL, SDA_IN, STARTOP) > > > begin > > > =A0 =A0if RST =3D '1' or SCL =3D '0' or STARTOP=3D'1' then > > > =A0 =A0 =A0 =A0STOPOP <=3D '0'; > > > =A0 elsif =A0SDA_IN =3D '1' and SDA_IN'event then > > > =A0 =A0 =A0 if SCL =3D '1' then > > > =A0 =A0 =A0 =A0 =A0 =A0 STOPOP <=3D '1'; > > > =A0 =A0 =A0 =A0end if ; > > > > =A0 end if; > > > =A0end process; > > > > Can =A0any one give me a reliable way to detect the start and stop > > > condition that =A0the synthesis tool doesnot give any setup time > > > violation. I am not using a high clock for sampling as the requiremen= t > > > is to use the SCL only. May be to save board resourse and space. > > > > Help will be appreciated. I am using Altera max II CPLD and the > > > synthesis tool is quartus 9.0 > > > > Thanks > > > > Vipul > > Dear Brad > > Thanks for your reply and for your time. Your suggestion is very > logical and I tried to implement it . The tool still gives an error in > the setup time though the slack reduced considerably . I will try to > work around it . > You have shown a good way to deal with it by making the two process > look symmetrical. > Thanks once again for your valuable time > > Vipul Having implemented with many I2C slaves in my projects I would like to add a few points: 1) If you don't want to sample the I2C signals with another clock, you WILL need schmitt-trigger inputs on your device. I2C rise times are very slow and can have a lot of noise while transitioning through the threshold region of most parts. Read the I2C spec to see the recommended hysteresis. By the way, this is why you need level translators to go from 3.3V to 5V I2C. The logic thresholds are ratiometric. 2) If you are using something like an FPGA without any schmitt trigger inputs, you need to de-glitch the SCL and SDA signals before you use them in your state machine. This is due to the possibility of multiple transitions being detected while the signal slowly rises through the threshold region. I have posted Verilog code for a simple I2C slave using a higher speed clock and deglitching on the Xilinx forums. Regards, GaborArticle: 140629
Evgeni, Ok neat. But why not just code the algorithm in straight verilog or VHDL, instead of C generates verilog? The C generated verilog code is unmanageable. CRC, and LFSR algorithms are the top of the list for implenting in hardware (i.e. HDLs) rather than C. C implementations are messy. You don't need to calculate "one-bit per clock" - rather one-bit per ITERATION. Who says each iteration must be a clock tick? Just implement the procedural code for the logic update of one bit and stick a 'for' loop around it for 'n' bits. Boom, done. Let the synthesis tool optimize, and produce the big XOR trees. The core of the verilog code that supports any polynomial (width, taps), and any data size could consist of less than 10 lines of code. --MarkArticle: 140630
I am running into problems when I am trying to synthesize a design with the plb_ddr2_v1_02_b IP core with Synplify. My project requires synthesizing the design from HDL source without any netlists. Currently, through XPS when synthesizing to netlists the ddr2 controller generates 3 EDIFs for Asynchronous FIFOs. These are: ddr2_sdram_32mx64_wrapper_async_fifo_v4_0_1.edn, ddr2_sdram_32mx64_wrapper_async_fifo_v4_0_2.edn, and ddr2_sdram_32mx64_wrapper_async_fifo_v4_0_3.edn. These EDIFs are generated through what appears to be an attribute in the proc_common_v2_00_b HDL file: coregen_comp_defs which uses the tool: edk_generatecore. My requirement to use only HDL source code forces me to find a solution to this problem. I am also constrained to use the PLB V3.4 (instead of the newer 4.6), so using a different interface such as the MPMC may not be possible (unless it is possible to backport the MPMC to the 3.4 PLB). It may be possible that Synplify is pruning out certain components or the Async FIFOs that we have generated to HDL via Xilinx netgen tool are not being mapped correctly. Any suggestions?Article: 140631
hassen.karray@gmail.com a écrit : > put a clock in your process : process(clk) but don't use it inernally, > it is just a syntax issue . WHAT ?! This is pure nonsense. Put your input signals in the sensitivity list : process (bus2, pin_11, pin_22) NicolasArticle: 140632
On May 17, 11:01=A0pm, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: # the direct FPGA version was optimized for single cycle operation # so every clock 24 bits of instruction and 2 16 bit words TOS/NOS are # fetched from BRAMs Why 24 bits of opcode ? - is that 3 opcode fetches at a time ? (Pascal-S seems to vary, up to 64 opcodes max ?) I also looked around for examples on Instruction List (IEC 61131) source and there are not a lot of non-trivial example-references, but there are some 'education free' working systems around, that can be used to test. This one looks good, and seems to work most examples in Simulate mode. http://www.61131.com/il.htm ( IL Bracket expression support, would use the stack.) http://www.61131.com/download.htm I think a core/tools could be made that maps well to _both_ Pascal-S and Instruction-List usage ? If it stays small enough, a LOT of these could fit into a FPGA. A core that is usable at both 'Quasi Assembler level', and HLL, could have longevity, and a tiny version would be usable for things like UART feeding & loaders. Wonder what your AVR loader, would be in IL syntax :) ? -jgArticle: 140633
Though I was familiar with Chuck Thacker's (designer of the Xerox Alto and Microsoft TabletPC) simple FPGA processor, I didn't know it was documented anywhere until a friend sent me this link a couple of days ago: http://www.bottomup.co.nz/mirror/Thacker-A_Tiny_Computer-3.pdf This paper includes the Verilog sources. As it is, it reminds me of a fat 32 bit version of Picoblaze but it is trivial to implement some of the expansions that are suggested. -- JecelArticle: 140634
On May 21, 9:53=A0am, Jecel <je...@merlintec.com> wrote: # http://www.bottomup.co.nz/mirror/Thacker-A_Tiny_Computer-3.pdf Nice, I like the 'fat' register area, as that is one area FPGAs have almost for free. I also see the extension notes to allow multiple contexts, or virtual cores, which is another natural extension from the BRAMs [" The second extension addresses the lack of interrupts. Since the BRAM holding the registers can hold eight full register contexts, it should be straightforward to provide a mechanism similar to that of the Alto. A separate three-bit Context register would hold the current context. Saving and restoring the current context=92s PC on a task switch is a bit problematic, but it is probably fairly straightforward."] This could, of course, map to more than 8, with a simple ROM if you only needed a smaller register array for some contexts. (eg 4 x 128R cores, and 16 x 32R cores) -jgArticle: 140635
In comp.arch.fpga Mark <mark@cacurry.net> wrote: (snip) < CRC, and LFSR algorithms are the top of the list for implenting in < hardware (i.e. HDLs) rather than C. C implementations are messy. (snip) < The core of the verilog code that supports any polynomial < (width, taps), and any data size could consist of less than < 10 lines of code. Note that Xilinx FPGAs can do 16 bits of LFSR in one SRL16, which takes up very little space. You could easily generate many of them, also wider than 16 bits. -- glenArticle: 140636
Hi,
I am trying to claim the following things in VHDL in
some written materials, and want to know if they are absolute
correct practically based on Xilinx FPGA implementations, not
theoretically on ModelSim
simulations.
signal X : unsigned(63 downto 0);
signal X0 : unsigned(63 downto 0);
signal X1 : unsigned(63 downto 0);
signal X2 : unsigned(63 downto 0);
signal X3 : unsigned(63 downto 0);
signal A1 : std_logic;
signal A2 : std_logic;
signal A3 : std_logic;
1. The following M1 and M2 process code implementations are the same:
M1 : process(..)
begin
X <= X0;
if A1 = '1' then
X <= X1;
if A2 = '1' then
X <= X2;
elsif A3 = '1' then
X <= X3;
end if;
end if;
end process;
M2 : process(..)
begin
if A1 = '1' then
if A2 = '1' then
X <= X2;
elsif A3 = '1' then
X <= X3;
else
X <= X1;
end if;
else
X <= X0;
end if;
end process;
2. The following M3 to M5 process code implementations are the same:
M3 : process(A1)
begin
if A1 = '1' then
X <= X1;
else
null;
end if;
end process;
M4 : process(A1)
begin
if A1 = '1' then
X <= X1;
end if;
end process;
M5 : process(A1)
begin
if A1 = '1' then
X <= X1;
else
X <= X;
end if;
end process;
3. The following M6 to M8 process code implementations are the same:
M6 : process(CLK)
begin
if CLK'event and CLK = '1' then
if A1 = '1' then
X <= X1;
else
null;
end if;
end if;
end process;
M7 : process(CLK)
begin
if CLK'event and CLK = '1' then
if A1 = '1' then
X <= X1;
end if;
end if;
end process;
M8 : process(CLK)
begin
if CLK'event and CLK = '1' then
if A1 = '1' then
X <= X1;
else
X <= X;
end if;
end if;
end process;
Thank you.
Weng
Article: 140637Hi, We are switching to a makefile to build our Xilinx FPGA bit files. Can we expect to get an identical bit file (except for date/time in the bitfile header) if we build through the ISE gui vs building via the command line? What we have found is that the output ngd file from the ngdbuild process (Translate) is not the same in both cases. The file size differs by 100 bytes, and the resulting bitfiles end up being very different. Can we expect the ngd file to be identical? We use synplicity to synthesize the design, which creates an edif netlist. The edif netlist going into the ISE flow and makefile flow are identical. Cheers AndrewArticle: 140638
Hi everyone, the latest version of GTKWave (3.2.1) windows binary is available at here: http://www.dspia.com/gtkwave.html Thanks to Tony now we have a way to start GTKWave without a file and open one later. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 140639
On May 20, 2:53=A0pm, Jecel <je...@merlintec.com> wrote: > Though I was familiar with Chuck Thacker's (designer of the Xerox Alto > and Microsoft TabletPC) simple FPGA processor, I didn't know it was > documented anywhere until a friend sent me this link a couple of days > ago: > > http://www.bottomup.co.nz/mirror/Thacker-A_Tiny_Computer-3.pdf > > This paper includes the Verilog sources. As it is, it reminds me of a > fat 32 bit version of Picoblaze but it is trivial to implement some of > the expansions that are suggested. Very interesting. Thanks Jecel. The two phase clock is certainly unusual for a small core like this. It would probably be more practical to sacrifice a bit of performance to get it to a more standard single clock (with two cycles pr instruction). What is the license terms for this? Public domain? Now we just need a backend for GCC/LLVM/LCC/... TommyArticle: 140640
> Hi, > We are switching to a makefile to build our Xilinx FPGA bit files. Can > we expect to get an identical bit file (except for date/time in the > bitfile header) if we build through the ISE gui vs building via the > command line? > What we have found is that the output ngd file from the ngdbuild > process (Translate) is not the same in both cases. The file size > differs by 100 bytes, and the resulting bitfiles end up being very > different. Can we expect the ngd file to be identical? > > We use synplicity to synthesize the design, which creates an edif > netlist. The edif netlist going into the ISE flow and makefile flow > are identical. > > Cheers > Andrew Are you sure that the settings you are using are identical. I was under the impression that ISE was just a GUI wrapper that sent commands to a common set of implementation programs. ---Matthew HicksArticle: 140641
On May 16, 6:12=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > radarman <jsham...@gmail.com> wrote: > > (snip) > > > I'm essentially looking for a board that has MII/GMII on one side, and > > an RJ-45 connector on the other. These exist, but cost hundreds of > > dollars. (the EVB-LAN8700 would be perfect, if it wasn't nearly $300!) > > Does anyone know of a cheap (~$50) board that essentially does the > > above? 10/100 would be fine. > > The Spartan3E board has built in 10/100 PHY, supply your > own MAC. =A0That is $150, so more than $50, less than $300. > > -- glen I'm already set up for Altera, though the Spartan 3e board is tempting. However, I've priced the parts for a board at under $20. In particular, Micrel has a 10/100 Phy for ~$6.50, and a Magjack RJ45 with integrated magnetics goes for about $9. That's really about it, save for a few biasing resistors, bypass caps, ferrite beads, and some header strip. The PCB's will likely cost a bit, but I suspect a simple 4-layer board will suffice - which most prototype places can do for cheap. Hopefully, if the boards work, I can sell the extras to recoup a bit of the cost.Article: 140642
On May 21, 12:17=A0am, Tommy Thorn <tommy.th...@gmail.com> wrote: > On May 20, 11:05=A0am, CMOS <manusha1...@gmail.com> wrote: > > > > > hi all, > > im planning to implement barcode scanning using a CMOS sensor. The > > processing needs to happen inside a FPGA, so im evaluating my options > > in choosing a proper soft processor for the task. these are my > > requirements. > > > 1) open source and need to be able to be used in commercial products > > 2) need to have good documentation and support tools (toolchain, > > simulators, emulators) > > 3) robust and stable > > 4) need to use in an xilinx spartan 3 device with 400K gates. > > > i know about processors OpenRISC 1000, NIOS 2 and LEON 2, but not sure > > how good they are with regard to my requirements, specially the (2), > > (3) and (4) above. Please help. > > > in addition, i like to here about microblaze and its licensing fees > > structure > > A few points: > - Nios II and MicroBlaze aren't open source, but both are very good. > - Is OpenRISC 1000 ok for commercial products? > - I doubt LEON 2 (and maybe OpenRISC 1000) can fit in "400K gates" > > You could also consider YARI (http://yari.thorn.ws). It's a bit weak > in the documentation department though but has great tools. The > hardware debugger still work in progress, but YARI has excellent > simulation support. > > Regards, > Tommy thanks tommy. why do you think OpenRISC 1000 is not suitable for commercial projects? thanks.Article: 140643
On May 21, 7:30=A0am, CMOS <manusha1...@gmail.com> wrote: > On May 21, 12:17=A0am, Tommy Thorn <tommy.th...@gmail.com> wrote: > > > > > On May 20, 11:05=A0am, CMOS <manusha1...@gmail.com> wrote: > > > > hi all, > > > im planning to implement barcode scanning using a CMOS sensor. The > > > processing needs to happen inside a FPGA, so im evaluating my options > > > in choosing a proper soft processor for the task. these are my > > > requirements. > > > > 1) open source and need to be able to be used in commercial products > > > 2) need to have good documentation and support tools (toolchain, > > > simulators, emulators) > > > 3) robust and stable > > > 4) need to use in an xilinx spartan 3 device with 400K gates. > > > > i know about processors OpenRISC 1000, NIOS 2 and LEON 2, but not sur= e > > > how good they are with regard to my requirements, specially the (2), > > > (3) and (4) above. Please help. > > > > in addition, i like to here about microblaze and its licensing fees > > > structure > > > A few points: > > - Nios II and MicroBlaze aren't open source, but both are very good. > > - Is OpenRISC 1000 ok for commercial products? > > - I doubt LEON 2 (and maybe OpenRISC 1000) can fit in "400K gates" > > > You could also consider YARI (http://yari.thorn.ws). It's a bit weak > > in the documentation department though but has great tools. The > > hardware debugger still work in progress, but YARI has excellent > > simulation support. > > > Regards, > > Tommy > > thanks tommy. > > why do you think OpenRISC 1000 is not suitable for commercial > projects? > > thanks. it doesnt fir s3-400 as a starter AnttiArticle: 140644
On May 21, 12:21=A0am, -jg <Jim.Granvi...@gmail.com> wrote: > On May 17, 11:01=A0pm, "Antti.Luk...@googlemail.com"<Antti.Luk...@googlem= ail.com> wrote: > > # the direct FPGA version was optimized for single cycle operation > # so every clock 24 bits of instruction and 2 16 bit words TOS/NOS are > # fetched from BRAMs > > Why 24 bits of opcode ? - is that 3 opcode fetches at a time ? > (Pascal-S seems to vary, up to 64 opcodes max ?) > i should have said 24 bits made up from a byte holding opcode and 16 bit operand > I also looked around for examples on Instruction List (IEC 61131) > source > and there are not a lot of non-trivial example-references, but there > are some 'education free' working systems around, that can be used to > test. > > This one looks good, and seems to work most examples in Simulate mode.htt= p://www.61131.com/il.htm > ( IL Bracket expression support, would use the stack.)http://www.61131.co= m/download.htm > > I think a core/tools could be made that maps well to _both_ Pascal-S > and Instruction-List usage ? > If it stays small enough, a LOT of these could fit into a FPGA. > IL core would be simple for FPGA sure, but i think the IL is mostly processed by some processor, eg interpreted > A core that is usable at both 'Quasi Assembler level', and HLL, could > have > longevity, and a tiny version would be usable for things like UART > feeding & loaders. > > Wonder what your AVR loader, would be in IL syntax :) ? > > -jg Jim, it actually doesnt matter that much, see the only reason i had to push the SD bootstrap was to fit to 128 byte flash ram space of actel proasic3 for any other FPGA families there is more initial bootstrap rom available so the size of bootstrap isnt that critical AnttiArticle: 140645
On May 21, 6:06=A0am, Tommy Thorn <tommy.th...@gmail.com> wrote: > On May 20, 2:53=A0pm, Jecel <je...@merlintec.com> wrote: > > > Though I was familiar with Chuck Thacker's (designer of the Xerox Alto > > and Microsoft TabletPC) simple FPGA processor, I didn't know it was > > documented anywhere until a friend sent me this link a couple of days > > ago: > > >http://www.bottomup.co.nz/mirror/Thacker-A_Tiny_Computer-3.pdf > > > This paper includes the Verilog sources. As it is, it reminds me of a > > fat 32 bit version of Picoblaze but it is trivial to implement some of > > the expansions that are suggested. > > Very interesting. Thanks Jecel. > > The two phase clock is certainly unusual for a small core like this. > It would probably be more practical to sacrifice a bit of performance > to get it to a more standard single clock (with two cycles pr > instruction). > > What is the license terms for this? Public domain? > > Now we just need a backend for GCC/LLVM/LCC/... > > Tommy there is also TC5 available with full sources if you search its a newer version of the TC, it has some assembler included in the package TC5 is licensed as MSL Microsoft Reseach License what says rree for non commercial AnttiArticle: 140646
On May 21, 3:37=A0pm, Matthew Hicks <mdhic...@uiuc.edu> wrote:
> Are you sure that the settings you are using are identical. =A0I was unde=
r
> the impression that ISE was just a GUI wrapper that sent commands to a co=
mmon
> set of implementation programs.
Hi Matthew,
I'm working with Andrew on this project.
The settings are not identical because ngdbuild.exe invoked by ISE has
an '-ise project.ise' and '-intstyle ise' options. We want to avoid
the use of the .ise project file entirely.
Also it seems that the GUI calls a different set of executables in the
"unwrapped" subdirectory of "ISE/bin/nt". It also passes the ISE
project file as a parameter and there's evidence that some settings
(such as the UCF file) are drawn from this. As I mention later,
running the same executable as the ISE generates a strange fatal
exception.
Let me try and describe the issue fully.
- we are using Xilinx 10.1 service pack 3 on Windows XP, and a recent
installation of Cygwin.
- we are trying to incorporate Xilinx into our automated build system
- so we are running the Xilinx command-line applications from a GNU
Makefile invoked from a Cygwin bash shell.
- we want to avoid the project .ise file completely as this seems to
change every time anyone opens it - this makes build tracking
difficult and therefore the .ise file is unsuitable as an input to our
automated build process.
- we first synthesize an EDIF file with Synplify 9.6.2 - this is
called FPGA_DAC16V2.edf in the examples below
- the Xilinx Project Navigator ISE file contains just two sources:
FPGA_DAC16V2.edf
Constraints/FPGA_DAC16V2.ucf
Once we have our EDIF, we wanted to see how to drive the Xilinx
Translate process (ngdbuild.exe) from the command line:
- the <project>.cmd_log file that Project Navigator creates during
Translate shows ngdbuild executing as follows:
ngdbuild -ise "D:/DAC_16v2/FPGA_DAC16V2/PAR/FPGA_DAC16V2/
FPGA_DAC16V2.ise" -intstyle ise -dd _ngo -nt timestamp -i -p xc3s1000-
ft256-4 "D:/DAC_16v2/FPGA_DAC16V2/Synthesis/FPGA_DAC16V2/rev_1/
FPGA_DAC16V2.edf" FPGA_DAC16V2.ngd
- hmm, there are two 'ngdbuild.exe' programs under .../ISE/bin/nt -
which one is being run? We think it's 'bin/nt/unwrapped/ngdbuild.exe'.
- anyway, we note the '-i' option means 'ignore the User Constraints
File', although the log output shows:
...
Reading in constraint information from 'Constraints/
FPGA_DAC16v2.ucf'...
...
- we believe ngdbuild is picking up the presence of this UCF file
from the referenced .ise file, but perhaps not actually applying the
constraints due to -i option.
- now, because we want to remove the .ise file from our process, we
manually converted this into the following command using "xflow"
integration:
D:/Xilinx/10.1/ISE/bin/nt/ngdbuild.exe -intstyle xflow -dd _ngo -nt
timestamp -i -p xc3s1000-ft256-4
"D:/DAC_16v2/FPGA_DAC16V2/Synthesis/FPGA_DAC16V2/rev_1/
FPGA_DAC16V2.edf" FPGA_DAC16V2.ngd
However the log output from this shows that this time, the constraint
information is not read, presumably because ngdbuild does not know
about the UCF file. This also results in a file about 100kb smaller
than the ISE generated .ngd file - certainly a different output. If
the entire process is run to generate a .bit file, a binary diff shows
these two .bit files as *significantly* different.
- so we determine that the UCF is probably required, changing the
command line to (replacing -i with -uc <file>):
D:/Xilinx/10.1/ISE/bin/nt/ngdbuild.exe -intstyle xflow -dd _ngo -nt
timestamp -uc Constraints/FPGA_DAC16V2.ucf -p xc3s1000-ft256-4 "D:/
DAC_16v2/FPGA_DAC16V2/Synthesis/FPGA_DAC16V2/rev_1/FPGA_DAC16V2.edf"
FPGA_DAC16V2.ngd
HOWEVER
Instead of "Reading in constraint information from 'Constraints/
FPGA_DAC16v2.ucf'..." we see this instead:
...
Applying constraints in "d:/DAC_16v2/FPGA_DAC16V2/PAR/FPGA_DAC16V2/
Constraints/FPGA_DAC16V2.ucf" to the design...
...
This is not what the ISE flow said it was doing. It read the UCF file
but it certainly didn't say it was applying the constraints!
Not only this, but the resulting .ngd file is still different - in
this case, the ISE generated .ngd file is 5333871 bytes and the one
generated by the commandline is only 5333798 bytes, or 73 bytes
smaller. A binary diff shows the files are almost entirely different.
This results in all other files beyond ngdbuild (such as map, par,
etc) to be different too. And the problem is, we don't know what is
actually different!
Interestingly, although all the resulting intermediate files that
follow on from this are different between the two processes, the
final .bit file is thankfully identical except for a few bytes that
look like a timestamp near the top of the file. This is a huge relief!
However we would still like to know what is going on because if we
can't generate identical ngd files, or at least be sure that they
differ only by a timestamp, then building confidence in our build
system will be difficult. Who is to say that future builds will
deviate in unknown ways?
We would like the output from ISE to exactly match the output from the
commandline, and if this is not possible then we'd like to know why
the two output files differ.
This raises a few questions:
1. is the .ngd output file encrypted or perhaps compressed? This would
explain the massive difference in the two files, especially if there's
a timestamp embedded in them.
2. how can we get the output .ngd files to be the same without
referencing the .ise file - what are we missing on the command line?
3. why does the ISE flow appear to not apply the UCF constraints, yet
if we don't do this with our command-line build, the resulting .bit
file is completely different.
4. why does the .ise Project file continually change? Even running
'ngdbuild -ise FPGA_DAC16V2.ise -h' to display the program's HELP text
causes the .ise file to change! Why? This makes it very difficult to
manage in a Source Control tool because it's continually changing
without a clear reason.
5. what is the difference between the file .../ISE/bin/nt/ngdbuild.exe
and .../ISE/bin/nt/unwrapped/ngdbuild.exe? The 'unwrapped' version of
ngdbuild.exe is used by ISE but when used in the example command-lines
above it frequently fails to find the UCF file and aborts:
ERROR:ProjectMgmt:356 - Problem loading constraints.
...
FATAL_ERROR:NgdBuild:Portability/export/Port_Main.h:143:1.6 - This
application
has discovered an exceptional condition from which it cannot
recover.
Process will terminate. For technical support on this issue, please
open a
WebCase with this project attached at http://www.xilinx.com/support.
I assume from this that we are not supposed to be calling the
'unwrapped' version of the exe file? Perhaps this is for internal ISE
use only?
So it appears it is not possible to run a). the same ngdbuild
executable, or b). the same command line options if you want to
completely avoid referencing the ISE project file with a command-line
invocation of ngdbuild.
-- David Antliff
Article: 140647"MikeWhy" <boat042-nospam@yahoo.com> wrote in message news:eRZQl.30176$Ws1.8735@nlpi064.nbdc.sbc.com... > "HT-Lab" <hans64@ht-lab.com> wrote in message > news:51YQl.67411$M64.58819@newsfe26.ams2... >> >> "MikeWhy" <boat042-nospam@yahoo.com> wrote in message >> news:odWQl.17139$%54.3159@nlpi070.nbdc.sbc.com... >>> "HT-Lab" <hans64@ht-lab.com> wrote in message >>> news:W7QQl.80572$861.55894@newsfe12.ams2... >>>> Does anybody know how to disable the CONV_INTEGER warnings in ISIM >>>> (11.1)? >>>> >>>> at 3000290500 ps(1), Instance /cpu_top_tb/U_12/ : Warning: >>>> CONV_INTEGER: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, >>>> and it has been converted to 0. >>>> at 3000365500 ps(1), Instance /cpu_top_tb/U_12/ : Warning: >>>> CONV_INTEGER: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, >>>> and it has been converted to 0. >>> >>> Only just guessing at the context... I would think ISIM's post-route >>> simulation elaborator is complaining that it's forcing to '0' an >>> uninitialized integer referenced in a math operation. >>> >> Hi Mike, >> >> Yes you are correct, these message are normally generated by >> Synopsys/IEEE packages and in Modelsim I just turn them off. I know >> what's causing them and fixed the issue by changing the code, however, it >> would be useful to have an option to turn them off. > > Hmmm. 'U' + 'X' is useful? ;) Selectively ignorable, yes, but habitually > ignoring them silently does sound potentially problematic. > It is quite easy to get gazillions of these messages in VHDL, for example before a reset is asserted or a tri-state bus feeding into an adder (as was in my case). These warnings prevents you from seeing any other messages. It also seriously hampers your simulation performance since writing to the transcript window (at least in Modelsim) is a real performance hog. Hans www.ht-lab.comArticle: 140648
On Wed, 20 May 2009 18:50:56 -0700 (PDT), Weng Tianxiang wrote: >I am trying to claim the following things in VHDL in >some written materials, and want to know if they are absolute >correct practically based on Xilinx FPGA implementations, not >theoretically on ModelSim simulations. That's a very strange way to look at it. The VHDL language is defined by its simulation semantics. Synthesis creates hardware that conforms to a certain (very useful) subset of those behaviours. It makes no sense to say that your understanding of VHDL is "absolutely correct... based on FPGA implementations". On the other hand, you CAN reasonably ask "do these two pieces of VHDL code imply identical synthesised hardware?". >signal X : unsigned(63 downto 0); >signal X0 : unsigned(63 downto 0); >signal X1 : unsigned(63 downto 0); >signal X2 : unsigned(63 downto 0); >signal X3 : unsigned(63 downto 0); >signal A1 : std_logic; >signal A2 : std_logic; >signal A3 : std_logic; > >1. The following M1 and M2 process code implementations are the same: > >M1 : process(..) >begin > X <= X0; > if A1 = '1' then > X <= X1; > if A2 = '1' then > X <= X2; > elsif A3 = '1' then > X <= X3; > end if; > end if; >end process; > >M2 : process(..) >begin > if A1 = '1' then > if A2 = '1' then > X <= X2; > elsif A3 = '1' then > X <= X3; > else > X <= X1; > end if; > else > X <= X0; > end if; >end process; Well... single-stepping through the two pieces of code in a simulator will of course show slightly different sequences of activity, but I agree that the externally-visible results of the two processes should be identical. It is impossible to tell the difference between Y <= A; Y <= B; -- completely replaces assignment Y<=A and Y <= B; (unless the evaluation of expression A has side-effects, of course). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >2. The following M3 to M5 process code implementations are the same: > >M3 : process(A1) >begin > if A1 = '1' then > X <= X1; > else > null; > end if; >end process; > >M4 : process(A1) >begin > if A1 = '1' then > X <= X1; > end if; >end process; I agree that these two are identical in every meaningful way. "null;" really does nothing. >M5 : process(A1) >begin > if A1 = '1' then > X <= X1; > else > X <= X; > end if; >end process; No, this is not the same. In M5 but not in M4, when A1 transitions to a value that is not '1', signal X is written; there will be no value-change on X as a result, for sure, but there *is* a transaction on X and that could be detected, outside the process, with the 'transaction, 'active or 'quiet attributes. None of the processes M3 to M5 follow any conventional synthesis template. If you had included X1 in the sensitivity list, they would all be perfectly good descriptions of a transparent latch. If you had rewritten the condition as "if rising_edge(A1)" they would all be perfectly good descriptions of a register. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >3. The following M6 to M8 process code implementations are the same: > >M6 : process(CLK) >begin > if CLK'event and CLK = '1' then > if A1 = '1' then > X <= X1; > else > null; > end if; > end if; >end process; > >M7 : process(CLK) >begin > if CLK'event and CLK = '1' then > if A1 = '1' then > X <= X1; > end if; > end if; >end process; M6 and M7 are completely identical in behaviour, yes. >M8 : process(CLK) >begin > if CLK'event and CLK = '1' then > if A1 = '1' then > X <= X1; > else > X <= X; > end if; > end if; >end process; Same discussion as for M5, above. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 140649
I created an account and downloaded it. Then I noticed the one month license and no pricing. Perhaps you might post again when you have decided whether I can afford it at which point I will try it. Your website promises many of the things I've always wanted from an editor. Colin
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