Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi, I have an I/Q OFDM analog signal on FIFO (like this is built is not topic of the post). I read from this FIFO with NCO at frequency of "64MHz / 7 (9.142857143 MHz)". The NCO clock is 64 MHz. The read signal as 64MHz timing and pulse at 9.142857143 MHz. Now I have the need to interpolate this signal x2 to obtain a 18.285714286 MHz of sample rate. How interpolate this signal with 64MHz of clock and 9.142857143 MHz of sample time ? I still can not dissociate the main clock from the sample time ... :-| ... Anyone have any idea ? Kappa.Article: 140651
On May 21, 9:35=A0am, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > 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 optio= ns > > > > 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 product= s > > > > 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 s= ure > > > > 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 > > Antti hi again, i decided to go with LEON 2 processor, but i could not find a download location for it. Can some one point me to a link? thanksArticle: 140652
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:ri0a15dqak38clq3j8uuvb2tl6lusob9lu@4ax.com...
>>
>>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.
>
>>
>>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.
>
I'm missing the point here. The sensitivity list for M4 and M5 only
includes A1, so any change in X1 doesn't propagate through to X in either
case.
Also, are you suggesting that an X <= X; would be seen as a transaction
within a sensitivity list?
M9: process (X)
begin
if X = '1' then
Y <= Y1;
end if;
end process;
where Y will take on the value of Y1, despite no change in X?
Article: 140653On Thu, 21 May 2009 09:46:57 +0100, "Fredxx" wrote: >> 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. [...] >I'm missing the point here. The sensitivity list for M4 and M5 only >includes A1, so any change in X1 doesn't propagate through to X in either Right. So the description is not a piece of synthesisable hardware; it's neither a latch, nor a register, nor a combinational function. I agree that the externally observable simulation behaviour would be the same for all those examples, apart from the 'transaction thing I mentioned. But it's not very useful. >Also, are you suggesting that an X <= X; would be seen as a transaction >within a sensitivity list? No. Be careful about the terminology; sensitivity lists see EVENTS, i.e. value-changes, on a signal; there is of course no such event as a result of X<=X. However, there is a TRANSACTION, an attempt to update X. You can't ordinarily see transactions in VHDL, but you can detect them using the built-in attributes I mentioned. >M9: process (X) >begin > if X = '1' then > Y <= Y1; > end if; >end process; > >where Y will take on the value of Y1, despite no change in X? Sorry, I don't see what you're asking here. If there's no change in X's value then the process won't run and Y won't update. In a real hardware transparent latch, you DO expect Y to follow the input Y1 if the enable X is asserted; you can easily get this by including both X and Y1 in the sensitivity list, and that gives you a good synthesisable description of a transparent latch. -- 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: 140654
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message news:g85a15lp0jd5kap4u0n5rlbq82k2l3mbh1@4ax.com... > On Thu, 21 May 2009 09:46:57 +0100, "Fredxx" wrote: > >>> 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. > [...] >>I'm missing the point here. The sensitivity list for M4 and M5 only >>includes A1, so any change in X1 doesn't propagate through to X in either > > Right. So the description is not a piece of synthesisable > hardware; it's neither a latch, nor a register, nor a > combinational function. I agree that the externally > observable simulation behaviour would be the same for > all those examples, apart from the 'transaction thing > I mentioned. But it's not very useful. > >>Also, are you suggesting that an X <= X; would be seen as a transaction >>within a sensitivity list? > > No. Be careful about the terminology; sensitivity lists see > EVENTS, i.e. value-changes, on a signal; there is of course > no such event as a result of X<=X. However, there is a > TRANSACTION, an attempt to update X. You can't ordinarily > see transactions in VHDL, but you can detect them using > the built-in attributes I mentioned. > It is synthsisable but perhaps not tgive the intended result. In essence an event on A1 and A1 = 1, would cause the value X1 to be latched into X. In both cases? >>M9: process (X) >>begin >> if X = '1' then >> Y <= Y1; >> end if; >>end process; >> >>where Y will take on the value of Y1, despite no change in X? > > Sorry, I don't see what you're asking here. If there's no change > in X's value then the process won't run and Y won't update. > In a real hardware transparent latch, you DO expect Y to follow > the input Y1 if the enable X is asserted; you can easily get this > by including both X and Y1 in the sensitivity list, and that gives > you a good synthesisable description of a transparent latch. That was my point, how would a transaction on X be "seen"? I thought VHDL was all about events.Article: 140655
colin_toogood@yahoo.com wrote:
> 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.
The beta program conditions are explained here:
http://www.sigasi.com/betaconditions
Jan
Article: 140656On May 21, 11:42=A0am, CMOS <manusha1...@gmail.com> wrote: > On May 21, 9:35=A0am, "Antti.Luk...@googlemail.com" > > > > <Antti.Luk...@googlemail.com> wrote: > > 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. Th= e > > > > > processing needs to happen inside a FPGA, so im evaluating my opt= ions > > > > > 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 produ= cts > > > > > 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 fe= es > > > > > 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 wea= k > > > > 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 > > > Antti > > hi again, > > i decided to go with LEON 2 processor, but i could not find a download > location for it. Can some one point me to a link? > > thanks LEON-2 is deprecated, if using LEON should take 3 and: while LEON just may fit s3-400 (I have done that) it leave no resources left for you so it is not an option for s3-400 AnttiArticle: 140657
Hi All,
I need a clock of 2.5 MHz and its 90 degree phase shifted version to
work with 10Mbps ethernet MAC on 1G/100M/10M PHY. I have a clock of
125 MHz and to comply with the DCM requirements, I have derived a
clock of 40 MHz from 125 MHz using DCM. Now, I have derived a clock of
2.5 MHz for RGMII interface (because PHY is RGMII based) from 40 MHz
using counters. For this, I have produced the 40 MHz true and 90
degree phase shifted clock and then derived 2.5 MHz clocks from both
of the versions (to get clock with 0 degree and 90 degree). But, as I
suspect, it is not the correct solution as 90 degree for 40 MHz has a
different time span than that of 2.5 MHz. I want to know how can I
produce 90 degree phase shifted 2.5 MHz clock from 125 MHz clock.
Following is the code that i have used
IBUF ibufg_gtx_clk (.I(gtx_clk), .O(gtx_clk_ibufg));
dcm_40M_out dcm_40M_out_inst(
.CLKIN_IN(gtx_clk_ibufg),
.RST_IN(reset),
.CLKFX_OUT(gtx_clk_40M),
.CLK0_OUT(),
.LOCKED_OUT()
);
dcm_40M_90 dcm_40M_90_inst(
.CLKIN_IN(gtx_clk_40M_bufg),
.RST_IN(reset),
.CLK0_OUT(gtx_clk0_out),
.CLK90_OUT(gtx_clk90_out),
.LOCKED_OUT()
);
BUFGMUX BUFGMUX_TXCLK_25 (
.O(gtx_clk_40M_bufg),
.I0(gtx_clk_40M),
.I1(), // not used
.S(1'b0)
);
assign cntr_00deg_sum_out = cntr_00deg + 1;
assign cntr_90deg_sum_out = cntr_90deg + 1;
always@(posedge gtx_clk0_out)
begin
if(reset) cntr_00deg <= 0;
else cntr_00deg <= cntr_00deg_sum_out;
end
always@(posedge gtx_clk90_out)
begin
if(reset) cntr_90deg <= 0;
else cntr_90deg <= cntr_90deg_sum_out;
end
BUFGMUX BUFGMUX_TXCLK (
.O(tx_rgmii_clk_int),
.I0(cntr_00deg[4]),
.I1(cntr_90deg[4]), // not used
.S(1'b0)
);
BUFGMUX BUFGMUX_TXCLK90 (
.O(tx_rgmii_clk90_int),
.I1(cntr_00deg[4]), // not used
.I0(cntr_90deg[4]),
.S(1'b0)
);
Article: 140658<colin_toogood@yahoo.com> wrote in message news:ab4b2e35-883a-4ae3-bd3d-e7e8bddae345@l32g2000vba.googlegroups.com... >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 Colin, If you email them they'll give you an outline of what they're thinking about pricing wise. I think they should publish this. NiallArticle: 140659
"HT-Lab" <hans64@ht-lab.com> wrote in message news:747Rl.100828$mS6.72054@newsfe27.ams2... > 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. I sometimes forget just how little I know, and appreciate your patient response.Article: 140660
On May 21, 10:42=A0am, CMOS <manusha1...@gmail.com> wrote: > On May 21, 9:35=A0am, "Antti.Luk...@googlemail.com" > > > > <Antti.Luk...@googlemail.com> wrote: > > 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. Th= e > > > > > processing needs to happen inside a FPGA, so im evaluating my opt= ions > > > > > 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 produ= cts > > > > > 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 fe= es > > > > > 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 wea= k > > > > 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 > > > Antti > > hi again, > > i decided to go with LEON 2 processor, but i could not find a download > location for it. Can some one point me to a link? > > thanks MicroBlaze is nice and easy to use, but with s3-400 you won't have much space left. Since the processor could not digest data in real time, you probably need a frame buffer also, so bigger FPGA is probably inevitable. You might consider taking this imaging development kit for a start: www.optomotive.si Cheers, AlesArticle: 140661
On Wed, 20 May 2009 10:32:06 +0100, "HT-Lab" <hans64@ht-lab.com> wrote: >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. I don't see these errors from CONV_INTEGER because I use numeric_std instead, but it looks like the same situation. My response is to identify the worst culprits and apply "to_01" functions in appropriate places. I usually live with the remainder which in my projects are confined to the first few hundred ns after reset as valid signals propagate through the pipelines. This way (a) I don't have to globally suppress the warning, so unexpected consequences of later changes can be caught as early as possible. (b) I am aware of where the "problem" is occurring and happy that it is only the result of expected (and allowed) circumstances as above. It sounds like a tedious task but you may be surprised by how few "to_01" functions are required; probably half a dozen on the designs I have experience of. - BrianArticle: 140662
On Thu, 21 May 2009 10:09:26 +0100, "Fredxx" wrote:
[regarding this example]
M4 : process(A1)
begin
if A1 = '1' then
X <= X1;
end if;
end process;
>It is synthsisable but perhaps not tgive the intended result.
>In essence an event on A1 and A1 = 1, would cause the value
>X1 to be latched into X.
I'm confused. I already explained, with justification,
why it's not correctly synthesisable, and then you tell
me it is...
Here's why that is BAD code for synthesis:
- The description, as you say, implies latching only on the
rising edge of A1. Like a D flop.
- But there is no "if A1'event" or "if rising_edge(A1)" in
the process. So it doesn't match the standard clocked
synthesis template.
In the synth tool I tried just now (Mentor Precision)
I got a warning about precisely this, telling me that
there might be synthesis/simulation mismatches (there will).
And it created a transparent latch, because - as usual -
for any non-clocked process, synthesis will assume a
complete sensitivity list. Personally I would prefer it
if synthesis tools were to reject the code as an error,
but that's not what happens; instead you get hardware
whose behaviour doesn't match the simulation. I'm fairly
sure that almost all mainstream synthesis tools behave
in a similar way on this example, but I can't be bothered
trying them all because it's code that should not be
synthesised.
>In both cases?
I already stated, correctly and with explanation, that
Weng's processes M4 and M5 have identical behaviour
in simulation. Both of them are inappropriate for
synthesis.
>how would a transaction on X be "seen"? I thought VHDL
>was all about events.
As I already pointed out, you can sense transactions in
simulation by using the 'transaction, 'active and 'quiet
built-in attributes. VHDL transactions have no use
in synthesis.
--
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: 140663On Wed, 20 May 2009 19:16:41 -0700 (PDT), andrew.newsgroup@gmail.com wrote: >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. > You'd like to think so, and if ALL the flags and options are identical, I believe it should be the case. But achieving that may not be trivial. Try running Translate from the command line with the exact command line given in the ".cmdlog" file - including the "-intstyle ISE" flag and see if that gives the same result as the GUI flow. The 'project.ise' can supposedly be exported as a script, reading which should help discover the missing options. These should then be applicable through the command line. However... One worrying datapoint is Xilinx's own PCIe interface project for the V5 ML506 board, where the advice given is to use the implementation shell script rather than attempting to build through the GUI; with no further explanation. Indeed an apparently successful run through the GUI tools produces a non-functional bitfile! I have not had time to explore deeply enough to find out why. - BrianArticle: 140664
On 20 mai, 23:19, Nicolas Matringe <nicolas.matri...@fre.fre> wrote: > hassen.kar...@gmail.com a =E9crit : > > > 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) > > Nicolas Dear Nicolas, You can put input signals in your sensitivity list ! you can also put your clock ... As long he'll not use any rising or falling edges , it will be synthesized the same way. Now, Talking about " pure nonsense " , assigning the same signal twice or more in the very same single process is theorically "pure nonsence" too, since only one single driver will be allowed finally ;) Either ways here, Synthsis tool will handle the design the same way and will finally put direct assignments , no clock, no input signals sensitive FF or latches ... We are talking here about a kind of tip to do things rapidly ... i agree with you that it is not academic though ! I have seen people with deep knowledge about synthesis and implementation tools doing awesome things with VHDL, they code in a " pure nonsence " style and get things working very quickly ... i somehow like that even though it doesn't garantee portability ... Best Regards, Hassen KARRAY.Article: 140665
I think we can summarize... M1 and M2 will synthesize to identical combinatorial circuits. There may be warnings about synthesis/simulations mis-matches if the sensitivity lists are not complete. M3, M4 and M5 will synthesize to identical combinatorial circuits, with a warning on the incomplete sensitivity list. M6 and M7 will synthesize to identical sequential circuits (D-flop with clk enable). M8 will synthesize to a sequential circuit with identical behavior (on a clock cycle basis) to that of M6 and M7, but the synthesis tool may try to build a feedback mux instead of using the built-in clk enable on the register. Different synthesis tools may handle this differently. It should be noted that if X were a port of mode OUT (or an alias thereof), then the processes that attempt to read X (M5 & M8) would not synthesize at all. It should also be noted that of M1 and M2, M1 is preferable for one significant reason: The default assignemnt to X up front makes it very easy to verify that M1 will not result in a latch. It is more difficult to verify that M2 will not result in a latch. AndyArticle: 140666
Hassen, Putting clock (and only clock) in the sensitivity list of a non- clocked process is pure nonsense when you (attempt to) simulate it. Recommending practices that categorically exclude simulation is pure nonsense. AndyArticle: 140667
Hi 72MHz it's hot! But cool. Lower un-necessary D_O pin state transitions etc. Estimated 17 MIPS on 8 bit bus. http://nibz.goglecode.com for download. Any improvements for speed or power efficiency while keeping low area welcome. BSD license, or 1 core (instruction stream) per chip (packaged semiconductor or logic substrate) license. 44% of MAX II 1270 C5 (527 LEs in speed technology) 8 Bit data bus, and ALU now 8 bit pipelined, as 16 bit is same space with no pipeline. ALU completion in following instruction fetch. 16 bit ISA. Stack style of programming. Clock possibly higher as critical path driven from latched value register. Interleave RW for full cycle RW_O = '0' on both hi and low byte (quite a large part of the design). A full Moore machine, all outputs driven by registers. In full custom this allows the large IO pad drivers to provide the feedback. Much of the instruction decode is pipelined due to most significant decoded bits are in the low byte. Should be suitable for interfacing to BRAM (with common address on read and write) or external SRAM. cheers jacko p.s. much of the pipelining is only possible with a low logic area because of the half width data bus dual fetching of data. Even though the design is big endian, the fetches and stores are done little endian for the usual carry propergation reasons, and for instruction decode efficiency.Article: 140668
David Antliff wrote:
> - 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.
As the .ise working file changes every run, and is binary to boot, it can
not be an input into a stable and maintainable build process. So the
solution I've used when using gnu make under Cygwin is to delete the
whole result directory (bld) at the start of the build. There are other
files in the result directory (and sub-directories under it) that can
influence the build, and the only way that I'm aware of to get a
consistent result is to start with a fresh directory.
Directory tree I've used looks something like this (Ascii art follows,
view with fixed pitch font)
Project
|
-----------
| |
src bld
|
-------
| |
hdl cores
The makefile exists in .src, and if any source file has changed it does
this:
rm -rf ../bld
mkdir ../bld
> 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.
One option for doing this would be to have the make file call a Project
Navigator Tcl script (using xtclsh). This script would create a
fresh .ise file every run, and could also be used to run from the GUI. I
posted a script for this sometime ago, and will update it if desired.
> 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!
This is because the ISE flow seems to read the UCF file into a data base
first, and then applies the constraints later.
> 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.
The .ise file has lots of date and time information. The solution to this
is to think of the .ise file as a working file, rather than a project
file and to delete it at the start of any build script. There are other
working files, such as the constraint data base (which lives in a
subdirectory of bld), and it is safest to delete them all by removing the
working directory. Even the command lines tools can create and use a .ise
file for their own use.
To difference the .bit files, the header needs to be ignored. To make
this automatic, I've written a little difference utility using Tcl. Would
this be of interest?
(phil_hays at eeei.gro (fix the order for email)
Article: 140669There are basically two ways. One is to change your main clock to a multiple of both frequencies, e.g. to 128 MHz. Another way is to run all your internal processing in burst mode at whatever frequency which is fast enough and then to bring the output to the real time though a single async fifo. /Mikhail <secureasm@gmail.com> wrote in message news:c5338a45-d4c4-404e-9a55-2df38e5ba843@g19g2000vbi.googlegroups.com... > Hi, > > I have an I/Q OFDM analog signal on FIFO (like this is built is not > topic of the post). I read from this FIFO with NCO at frequency of > "64MHz / 7 (9.142857143 MHz)". The NCO clock is 64 MHz. The read > signal as 64MHz timing and pulse at 9.142857143 MHz. Now I have the > need to interpolate this signal x2 to obtain a 18.285714286 MHz of > sample rate. > > How interpolate this signal with 64MHz of clock and 9.142857143 MHz of > sample time ? > > I still can not dissociate the main clock from the sample > time ... :-| ... > > Anyone have any idea ? > > Kappa.Article: 140670
On May 20, 11:24=A0am, Mike Treseler <mtrese...@gmail.com> wrote: > > No, that is a synthesis timing constraint. > > I can eliminate the requirement in my > code by adding a synchronous handshake > or pipeline. > > =A0 =A0 -- Mike Treseler Not sure I understand... MCP constraints relax timing on long combinatorial paths that need not complete in a single clock cycle (due to clock enables, etc). The only way to avoid them is to speed up the paths, or break them up into sequential sub-paths that will each complete in one clock cycle (pipeline). Seems like a lot of hard work to keep the synthesis/P&R tool from working harder/longer than it needs to (and probably failing) in the first place. The problem with MCP constraints is that it is very difficult to verify that they are properly applied, except with extensive post- route, full timing simulations. It is also easy to forget non-nominal situations in which those paths may not actually be MCPs. Users often fall into the trap of assuming that every input to every register that is only clock enabled once every N clocks necessarily has an MCP of N. There are reportedly tools available (expensive) that will perform formal analysis and either create accurate MCP constraints, or verify existing ones without simulation. If you know your MCP is correctly specified (you are relaxing constraints on the exact signals/paths you thought you were), you can use assertions in the RTL to verify them by ensuring that changes to the value of specific signals do not occur except as expected by the MCP constraint. If these assertions could be standardized (use standardized functions, etc), then perhaps synthesis could make use of them to create associated MCP constraints automatically. I'm thinking of a function something like: is_stable(input_name, N, clk_name, enable_name) returns boolean; (sorry this is in VHDL) that would verify the MC behavior of the signal during RTL simulation. AndyArticle: 140671
Hi Mikhail, thanks for your replay. > There are basically two ways. One is to change your main clock to a multiple > of both frequencies, e.g. to 128 MHz. This route is not viable, I choose the second solution. > Another way is to run all your internal processing in burst mode at whatever frequency which is fast enough > and then to bring the output to the real time though a single async fifo. I actually write to the FIFO in burst mode and read at the sample rate. At this point I should interpolate by two. According to your idea, if I understand correctly, write to the FIFO in burst mode but before write I apply the interpolator filter x2 and read from fifo at x2 sample rate. I have understood ? But how interpolate x2 before write to FIFO ? Kappa.Article: 140672
Syms, The DCM never attenuates jitter. It can not be accidentally 'correct' all the time (zig for every zag...). It is a delay line. What goes in, is guaranteed to come out. The DCM only changes one tap at a time (based on the FACTORY_JF setting, it is that number times 6 or 36 -- depending on family -- input clocks for one tap change). The FACTORY_JF is completely miss- leading, as the intent was to allow the DCM to tolerate input jitter, but correcting often, or not so often, does nothing to tolerate input jitter. And since it only updates one tap, the FACTORY_JF also does nothing to increase or decrease the output jitter. The only time we recommended changing the FACTORY_JF setting was for the Vccaux dV/dt ' issue' on Virtex II (subsequently fixed in all later devices). I suspect that if the output is a PWM signal, that jitter is no issue whatsoever, as the PWM signal is a signal that has potentially 100% "jitter" just to do what it is supposed to be doing. I am not sure what the poster really is concerned about. There is a hidden setting to freeze the DCM updates of the taps, but it really isn't of any use, other than for testing (does the added tap switch jitter break the design? If so, you are so close to your timing margin -- no slack -- that you really need to find and constrain the paths where the device has insufficient slack). AustinArticle: 140673
<secureasm@gmail.com> wrote in message news:174612d0-4248-4a61-beb5-81436c807109@3g2000yqk.googlegroups.com... > > According to your idea, if I understand correctly, write to the FIFO > in burst mode but before write I apply the interpolator filter x2 and > read from fifo at x2 sample rate. > > But how interpolate x2 before write to FIFO ? From the data stream point of view an interpolate by 2 filter is simply a device producing two output sample for each input sample. It can be run in burst mode at any frequency which is more or equal 2x your input sample frequency. If you are using Xilinx take a look at their FIR IP cores. /MikhailArticle: 140674
On May 21, 5:26=A0pm, jacko <jackokr...@gmail.com> wrote: > Hi > > 72MHz it's hot! But cool. Lower un-necessary D_O pin state transitions > etc. Estimated 17 MIPS on 8 bit bus. > > http://nibz.goglecode.comfor download. Any improvements for speed or > power efficiency while keeping low area welcome. > > BSD license, or 1 core (instruction stream) per chip (packaged > semiconductor or logic substrate) license. > > 44% of MAX II 1270 C5 (527 LEs in speed technology) > > 8 Bit data bus, and ALU now 8 bit pipelined, as 16 bit is same space > with no pipeline. ALU completion in following instruction fetch. 16 > bit ISA. Stack style of programming. > > Clock possibly higher as critical path driven from latched value > register. > > Interleave RW for full cycle RW_O =3D '0' on both hi and low byte (quite > a large part of the design). > > A full Moore machine, all outputs driven by registers. In full custom > this allows the large IO pad drivers to provide the feedback. Much of > the instruction decode is pipelined due to most significant decoded > bits are in the low byte. > > Should be suitable for interfacing to BRAM (with common address on > read and write) or external SRAM. > > cheers jacko > > p.s. much of the pipelining is only possible with a low logic area > because of the half width data bus dual fetching of data. Even though > the design is big endian, the fetches and stores are done little > endian for the usual carry propergation reasons, and for instruction > decode efficiency. goglecode? G-spot? have you ever found it? Antti
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