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 Mon, 9 Feb 2009 10:18:27 -0800 (PST), Antti <Antti.Lukats@googlemail.com> wrote: >On Feb 9, 8:07 pm, Brian Drummond <brian_drumm...@btconnect.com> >wrote: >> >So i did MINIMAL fix to get pass XST >> >that was not enough to pass with ISIM >> >> Interesting because that's exactly the conditions that gave me the XST above ... >> type mismatch between IEEE.STD_LOGIC_UNSIGNED (in the wrapper) and numeric_std >> (in Jonathan's code). >> >> So I don't see how you got it through XST... >Brian >plese LOOK below, my complete wrapper. >AS is it passes XST until bit file all ok. aha! The full code reveals the secret... cunningly exploiting a bug in XST to make it handle incorrect code! Because this uses a component declaration, XST can't error out here because it has to assume you will supply a matching entity at elaboration; if it was to check the available entities it could at best conclude you hadn't written it yet, which is completely legal... if you had used an entity as I did (reducing the work even further) it would have found the error (and did). So it's at elaboration the error occurred; XST couldn't find a matching entity, never mind, it used the first entity it could find with the right name and roughly the right number of ports! (which, being the masochist I am, I reported for ISE 7.1 and 10.1, and I'm told it should be fixed in 11) >but yikes in ISIM Good for ISIM, this time! - BrianArticle: 138226
On Mon, 09 Feb 2009 19:03:01 +0000, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: >let's see what the bug report should look like... > > Dear Xilinx, > XST compiled my code exactly the way I wanted it. > Please fix XST so that it will NOT compile my code. > Yours sincerely, > A. Masochist. > >I don't see Xilinx exactly being flooded with >that kind of case; do you? :-) Which explains quite a lot about the non-compliance of XST. And, arguably, it doesn't matter, because the code has already been thoroughly vetted in simulation, hasn't it? :-) It does get a bit more interesting when there are similar-looking (but different) entities with the same name, e.g. in different libraries, and XST picks the wrong one... - BrianArticle: 138227
Uwe Bonnes wrote: > > Anybody knows how to takeover the sourceforge xc3sprog project? I have put > my tarred svn trunk as patch on sourceforge, but downloader are requested > to give feedback, best in the form of patches. > They have a process set up to do that. Start off by emailing the current owner. If there is no response then check the sourceforge docs for how to get them to transfer ownership to you. John EatonArticle: 138228
On Feb 9, 3:58=A0pm, Gerhard Hoffmann <dk...@hoffmann-hochfrequenz.de> wrote: > On Sun, 08 Feb 2009 21:54:45 +0000, Jonathan Bromley <jonathan.brom...@MY= COMPANY.com> wrote: > >The last line requires TWO adders, in addition to the > >multiplexer created by the IF. =A0This causes a significant > >performance hit. =A0That's what I was trying to fix. =A0I did > >it by saying... > > You can add 3 numbers in the same time as 2 because the maximum > carry generated at any bit position is still '1'. > I.e. '1' + '1' + '1' is still '11'. > OK, works for 4-input LUTs. Did you forget 1 + 1 + 1 + carryin =3D 100 ? > 4 numbers will make the carry chain more complicated. > I have not tried if Virtex carry chains can take advantage of this. > If yes, the mux should be possible in the same block. 3 numbers make the carry chain more complex. I'm sure that if it were practical or even possible to add three numbers using a single 4 LUT, we would already know about it. RickArticle: 138229
On Feb 9, 5:14=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Sun, 8 Feb 2009 22:42:04 -0800 (PST), rickman wrote:
> >This is an interesting problem, am I understanding it correctly?
>
> Yes; more correctly than I did at first, I think.
>
> Various people have correctly pointed out that the N-M
> calculation does not need to be on a timing arc, but it's
> tough to convince the tools of that.
Tough, but not impossible. There is a way to tell the tools than any
path through a given point has a specified timing. You need to apply
this to the net which is the output of the adder of N-M.
> Other people have correctly pointed out that my trick
> to convert 2 adders and a 2-in MUX into one adder and
> a 3-in MUX does not save any area. =A0I did consistently
> find, however, that it gave significantly better Fmax;
> I'm not 100% sure I know why. =A0If we have 6-input LUTs
> then my trick would be a very big win.
I agree that the timing should be close between the two examples. But
adders have to be arranged in a column while the bits of a mux can be
placed anywhere close and will have good timing. I expect this is the
sort of design that can be helped significantly by floorplanning.
> Finally, someone pointed out that the N-M calculation
> could be pipelined. =A0In FPGAs, with one FF per LUT
> whether you use it or not, that turns out better than
> any other form I've tried. =A0
I'm not sure what is meant by that, but certainly it will not hurt to
add FFs to the output of N-M since they are virtually static for this
application. By adding FFs here, you will in essence be cutting the
timing path allowing the timing analyzer to see only the portions of
the design that need to be fast. In fact, you can eliminate the adder
altogether by having the programmed registers hold N and N-M instead
of N and M. That *will* increase speed as well as reducing
footprint.
> Better still, if N and M
> are both constants then the tools correctly identify
> that the (N-M) pipeline register is constant, and
> optimize it away. =A0So my original question, and my
> original "trick", become irrelevant (except in
> Spartan-6, maybe???!!!) and my "best effort" is:
I don't know what higher level muxes they have in the 6 series of
parts. A 6 input LUT is still not enough to support a 3 input mux and
a full adder. The LUT needs 5 inputs for the mux plus one for the
accumulator plus one more for the carry input to each bit.
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.numeric_std.all;
>
> entity rate_gen is
> =A0 generic ( ref_Hz: positive :=3D 50_000_000 );
> =A0 port
> =A0 =A0 ( clock : in =A0std_logic
> =A0 =A0 ; reset : in =A0std_logic
> =A0 =A0 ; rate =A0: in =A0unsigned
> =A0 =A0 ; pulse : out std_logic
> =A0 =A0 );
> end;
>
> architecture RTL of rate_gen is
>
> begin
> =A0 process (clock)
> =A0 =A0 variable count: integer range -2**rate'length to ref_Hz-1 :=3D 0;
> =A0 =A0 variable wrap: natural range 0 to ref_Hz :=3D ref_Hz;
> =A0 begin
> =A0 =A0 if rising_edge(clock) then
> =A0 =A0 =A0 pulse <=3D '0';
> =A0 =A0 =A0 if reset =3D '1' then
> =A0 =A0 =A0 =A0 count :=3D 0;
> =A0 =A0 =A0 elsif count < 0 then
> =A0 =A0 =A0 =A0 pulse <=3D '1';
> =A0 =A0 =A0 =A0 count :=3D count + wrap;
> =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 count :=3D count - to_integer(rate);
> =A0 =A0 =A0 end if;
> =A0 =A0 =A0 wrap :=3D ref_Hz - to_integer(rate);
> =A0 =A0 end if;
> =A0 end process;
> end;
>
> The synchronous reset adds a tiny amount of delay (routing???)
> and is probably unnecessary.
>
> But there's another idea coming...
Here is your code with two setup registers.
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity rate_gen is
generic ( ref_Hz: positive :=3D 50_000_000 );
port
( clock : in std_logic
; reset : in std_logic
; rate : in unsigned
; n_m : in unsigned
; pulse : out std_logic
);
end;
architecture RTL of rate_gen is
begin
process (clock)
variable count: integer range -2**rate'length to ref_Hz-1 :=3D 0;
begin
if rising_edge(clock) then
pulse <=3D '0';
if reset =3D '1' then
count :=3D 0;
elsif count < 0 then
pulse <=3D '1';
count :=3D count + n_m;
else
count :=3D count - to_integer(rate);
end if;
end if;
end process;
end;
Rick
Article: 138230On Feb 9, 5:57=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Mon, 09 Feb 2009 10:14:09 +0000, Jonathan Bromley wrote: > >But there's another idea coming... > > which is to time-division mux the two additions. > This degrades the jitter to 2 master clock periods, > but gives what I believe to be the most compact > and fastest possible implementation for a phase > accumulator whose modulus is not a power of 2. > I removed the reset because it's fairly useless. > > As with the earlier implementation, this one > can only provide output rates up to Fc/2. > > =A0 library ieee; > =A0 use ieee.std_logic_1164.all; > =A0 use ieee.numeric_std.all; > > =A0 entity rate_gen is > =A0 =A0 generic ( ref_Hz: positive :=3D 50_000_000 ); > =A0 =A0 port > =A0 =A0 =A0 ( clock : in =A0std_logic > =A0 =A0 =A0 ; rate =A0: in =A0unsigned > =A0 =A0 =A0 ; pulse : out std_logic > =A0 =A0 =A0 ); > =A0 end; > > =A0 architecture RTL_2ph of rate_gen is > =A0 begin > =A0 =A0 process (clock) > =A0 =A0 =A0 -- Halve the modulus to account for 2-phase operation > =A0 =A0 =A0 constant modulus: integer :=3D ref_Hz/2; > =A0 =A0 =A0 -- This flag controls the adder multiplexing > =A0 =A0 =A0 variable phase: boolean; > =A0 =A0 =A0 variable count: integer range -2**rate'length to modulus-1 := =3D 0; > =A0 =A0 begin > =A0 =A0 =A0 if rising_edge(clock) then > =A0 =A0 =A0 =A0 pulse <=3D '0'; > =A0 =A0 =A0 =A0 if phase then > =A0 =A0 =A0 =A0 =A0 count :=3D count - to_integer(rate); > =A0 =A0 =A0 =A0 elsif count < 0 then > =A0 =A0 =A0 =A0 =A0 count :=3D count + modulus; > =A0 =A0 =A0 =A0 =A0 pulse <=3D '1'; > =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 =A0 phase :=3D not phase; > =A0 =A0 =A0 end if; > =A0 =A0 end process; > > =A0 end; > > Thanks for all the comments. I don't get how this is smaller or faster than any of the other approaches. RickArticle: 138231
On Mon, 9 Feb 2009 14:13:23 -0800 (PST), Gabor wrote: >On Feb 8, 12:02 pm, Jonathan Bromley wrote: >> The question - repeated after the explanation - >> is: here's what I think is a nifty trick; has >> anyone seen it, or been aware of it, before? >> I can't believe it's really new. [...] >Did you see this thread on comp.lang.verilog? http://groups.google.com/group/comp.lang.verilog/browse_frm/thread/7cedbaf9bdd6f1ad?hl=en# No, I don't recall reading it... looks interesting. Thanks for the pointer. -- 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: 138232
>>You have to select the "Display ... IP Cores" under >>Edit->Preferences...->IP Catalog and IP Config Catalog in the XPS. >> >>Matthias > >I did it but there isn't >the PS2 INTERFACE in communication low-speed menł >and I don't understand the reason why... > Ok, ok... I had the 10.1 version... I've just upgraded edk to 10.1.03 version and there is xps ps2 interface in the ip catalog... thanks and sorry DanieleArticle: 138233
On Sun, 08 Feb 2009 23:23:00 GMT, Nico Coesel wrote:
>What if you simply add N-M to the accumulator?
>
> on every clock pulse...
> if (acc < 0) then
> acc := acc + (N -M);
> output_pulse <= '1';
> else
> output_pulse <= '0';
> acc := acc - M;
> end if;
That is very good if N and M are both constants,
but I wanted to deal with the case where M is
a variable and in that case we end up with two
adders which have to be cascaded somehow.
I revisited the problem for the case where N
and M are both constants, and noted that you
can easily precalculate the greatest common divisor
of N, M and thereby reduce the fraction M/N
to its lowest terms. This helps to minimize
the design without unnecessary human effort,
which rates pretty highly on my lazy man's
list of desiderata. Here's the code...
-- put this in a package, or in the architecture
entity fixed_rate_gen is
generic (divisor, multiplier: positive);
port (clock: in std_logic; pulse: out std_logic);
end;
architecture rtl of fixed_rate_gen is
function euclid_gcd(divisor, multiplier: positive)
return positive is
variable r0, r1, r: natural;
begin
assert multiplier <= divisor
report "Multiplier is greater than divisor"
severity failure;
r0 := multiplier;
r1 := divisor;
while r0 /= 0 loop
r := r1 rem r0;
r1 := r0;
r0 := r;
end loop;
return r1;
end;
constant gcd: positive := euclid_gcd(divisor, multiplier);
constant m: positive := multiplier/ gcd;
constant wrap: positive := (divisor / gcd) - m;
begin
process (clock)
variable acc: integer range -m to wrap-1 := 0;
begin
if rising_edge(clock) then
if acc < 0 then
acc := acc + wrap;
pulse <= '1';
else
acc := acc - m;
pulse <= '0';
end if;
end if;
end process;
end;
I love the Euclid GCD algorithm - so neat and
simple, so non-obvious (to me at least).
--
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: 138234hi everybody, i am using ise10.1, i have designed the stepper motor controller....it's going fine on ise upto pin assignment....but ise failed to place and route the design when i reimplemented design after the pin assignment.........The implementation of design was successful before the pin assignment....Only one Warning the Synthesis have.... So how can i fix this problem of place and routing......... Is this problem is due to warning during synthesis??? Warning in synthesis: I have 18-bit counter in my design and iam getting different frequencies from higher bits of counter and i am only using the upper 8-bits of counter....So error statement is: freq_in<9:0> are left unconnected............ error during reimplementation: Command Line: C:\Xilinx\10.1\ISE\bin\nt\unwrapped\ngdbuild.exe -ise I:/FPGAs_Design/ise_stepper_motor/ise_stepper_motor.ise -intstyle ise - dd _ngo -nt timestamp -i -p xc2s50-tq144-5 speed_controller.ngc speed_controller.ngd Reading NGO file "I:/FPGAs_Design/ise_stepper_motor/ speed_controller.ngc" ... Process "Translate" failed In first try, there was only place and routing failed but after that all the processes within the design implementation like Translation and mapping also get failed.... any help will be greatly appreciated....Article: 138235
On Feb 8, 5:52=A0pm, Alan Fitch <apfi...@invalid.invalid> wrote: > GrIsH wrote: > > hi all i have been trying to synthesize a module in ise. but while > > trying to assign the pins after generating ucf file following message > > was displayed > > > loading device for application Rf_device from file ''v50 nph' in > > environment C:\xilinx10.1\ise. > > ERROR:HDLParsers:3562 pepExtractor.prj line1Expecting 'vhdl' or > > 'verilog' keyword found 'work'. > > > i really dont know what to do. > > any suggestions would be highly appreciated. > > > thank you. > > Try google, which gives you: > > http://forums.xilinx.com/xlnx/board/message?board.id=3DISE&thread.id=3D11= 9 > > which says "don't have a space in your directory path", > > regards > Alan > > -- > Alan Fitch > apfitch at ieee > dot org Thnx for your help......It started working fine when i did what you said....Article: 138236
GrIsH wrote: > hi everybody, > i am using ise10.1, i have designed the stepper motor > controller....it's going fine on ise upto > pin assignment....but ise failed to place and route the design when i > reimplemented design > after the pin assignment.........The implementation of design was > successful before the pin assignment....Only one Warning the Synthesis > have.... > > So how can i fix this problem of place and routing......... > Is this problem is due to warning during synthesis??? > Warning in synthesis: I have 18-bit counter in my design and iam > getting different frequencies from higher bits of counter and i am > only using the upper 8-bits of counter....So error statement is: > freq_in<9:0> are left unconnected............ > > error during reimplementation: > Command Line: C:\Xilinx\10.1\ISE\bin\nt\unwrapped\ngdbuild.exe -ise > I:/FPGAs_Design/ise_stepper_motor/ise_stepper_motor.ise -intstyle ise - > dd _ngo > -nt timestamp -i -p xc2s50-tq144-5 speed_controller.ngc > speed_controller.ngd > > Reading NGO file "I:/FPGAs_Design/ise_stepper_motor/ > speed_controller.ngc" ... > > Process "Translate" failed > > In first try, there was only place and routing failed but after that > all the processes within the design implementation like Translation > and mapping also get failed.... > > any help will be greatly appreciated.... There should be more information somewhere. Try cleaning the project using the menu Project > Cleanup Project Files. Then run implementation again, and look at the reports very carefully to see what the error is, regards Alan -- Alan Fitch Doulos http://www.doulos.comArticle: 138237
On Tue, 10 Feb 2009 03:42:23 -0800 (PST), GrIsH <grishkunwar@gmail.com> wrote: >hi everybody, >i am using ise10.1, i have designed the stepper motor >controller....it's going fine on ise upto >Reading NGO file "I:/FPGAs_Design/ise_stepper_motor/ >speed_controller.ngc" ... > >Process "Translate" failed For "Process "Translate" failed" - the Translate report (mydesign.bld) should contain more information For "Process "MAP" failed" - the Map report (mydesign.par) should contain more information For "Process "Place and Route" failed" - the PAR report (mydesign.par) should contain more information - BrianArticle: 138238
On Feb 7, 11:28 am, jleslie48 <j...@jonathanleslie.com> wrote: > > The rest of you message I'll be addressing on Monday. > > Sincerely, > > Jonathan Leslie Ok, I'm having a ball with this version. I'm messing with it, and its messages scheme, and now I'm trying to build an actual reset button onto the data_gen process. All the baud rate stuff worked perfectly, and after I have the reset switch going, I think the next step is to update the goto functionality to be a goto LABEL instead of a PC location. So I think a good project is to add the 'OP_LABEL [char]' mnemonic and re-tool the goto to walk through the ROM?? looking for the label. - JonArticle: 138239
On Mon, 9 Feb 2009 16:32:44 -0800 (PST), rickman <gnuarm@gmail.com> wrote: >> OK, works for 4-input LUTs. > >Did you forget 1 + 1 + 1 + carryin = 100 ? Ouch, incorrectly remembered 3 to 2 counter principle. Should not write about such stuff late at night. GerhardArticle: 138240
Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote:
>On Sun, 08 Feb 2009 23:23:00 GMT, Nico Coesel wrote:
>
>
>>What if you simply add N-M to the accumulator?
>>
>> on every clock pulse...
>> if (acc < 0) then
>> acc := acc + (N -M);
>> output_pulse <= '1';
>> else
>> output_pulse <= '0';
>> acc := acc - M;
>> end if;
>
>That is very good if N and M are both constants,
>but I wanted to deal with the case where M is
>a variable and in that case we end up with two
>adders which have to be cascaded somehow.
You don't have to. Just say A=N-M and add A to the pulse accumulator.
A can be calculated in a seperate process.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 138241On Tue, 10 Feb 2009 08:33:14 -0800 (PST), jleslie48 wrote: > I think the next step is >to update the goto functionality to be a goto LABEL instead of >a PC location. So I think a good project is to add the >'OP_LABEL [char]' mnemonic and re-tool the goto to > walk through the ROM?? looking for the label. Or, maybe, scan the ROM just once at startup, cacheing the label addresses in a second blockRAM organized as a table of PC values indexed by character. It will still be a long way from Turing-completeness :-) and a very long way from doing any useful DSP :-( -- 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: 138242
On Feb 9, 9:03=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > On Feb 9, 6:09=A0pm, uraniumore...@gmail.com wrote: > > > > > > > On Feb 9, 1:36=A0am, Muzaffer Kal <k...@dspia.com> wrote: > > > > On Mon, 9 Feb 2009 01:18:21 -0800 (PST), uraniumore...@gmail.com > > > wrote: > > > > >Does anyone know how I can generate a pulser of maximum repition rat= e > > > >of 50 Mhz in verilog .. into my existing design ? I'd like to simula= te > > > >this signal before I use the actual pulser into the board > > > > I think you want a clock source. Here is one way you can generate it: > > > > `timescale 1ns/100fs > > > reg clk; > > > initial > > > begin > > > =A0 =A0 =A0 =A0 pck =3D 0; > > > =A0 =A0 =A0 =A0 forever clk =3D #10 ~clk; > > > end > > > > This clock toggles at 50 MHz as you want (ie 10ns high, 10 ns low) an= d > > > you can change the number 10 to your needs. > > > Please note that this is only for testbench usage and you can't > > > actually put this in your fpga. You have to use an oscillator on your > > > board to generate a similar clock to drive into your fpga. > > > > Muzaffer Kal > > > > DSPIA INC. > > > ASIC/FPGA Design Serviceshttp://www.dspia.com > > > Hi, > > > I was did make myself clear. I would like to have a variable pulesr, > > maximum 50 Mhz. > > > Thanks > > I think you made something very clear. > > Antti- Hide quoted text - > > - Show quoted text - Okay, I made a grammatical blunder there! All jokes aside...I wanted to know if there is some code out there that would generate a variable pulse of max 50Mhz... thanks again,Article: 138243
On Feb 10, 1:17 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Tue, 10 Feb 2009 08:33:14 -0800 (PST), jleslie48 wrote: > > I think the next step is > >to update the goto functionality to be a goto LABEL instead of > >a PC location. So I think a good project is to add the > >'OP_LABEL [char]' mnemonic and re-tool the goto to > > walk through the ROM?? looking for the label. > > Or, maybe, scan the ROM just once at startup, cacheing > the label addresses in a second blockRAM organized as > a table of PC values indexed by character. > > It will still be a long way from Turing-completeness :-) > and a very long way from doing any useful DSP :-( > -- > 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.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. even better ;) but being able to scan a rom for specific signals, (label) and caching them you don't consider a worthwhile process of a DSP?Article: 138244
Hi, for whatever reason not clear to me at this point, ISE-10.3 P&R use two BUFGMUX each on oposite side of FPGA to route an incoming clock. What I have is: Ext. clock => IBUFG => BUFG_1 => BUFG_2 => DCM_1/DCM_2/DCM3 IBUFG only drives BUFG_1 BUFG_1 drives BUFG_2 and also a shift register in a synchronous reset release BUFG_2 drives three DCMs and nothing more. I inspect the work that P&R has done in FPGA editor: IBUFG (replaced by the pad) and BUFG_1 are physically close and have 0.03 ns delay BUFG_1 and BUFG_2 are on opposite sides of FPGA and the connection is routed on sub-optimal wiring according to the report file from ISE. The delay is around 7 ns. I can verify this in FPGA editor, the wiring goes zig-zag into boxes (probably switch facilities) on its way between the two BUFGMUXes that the placer has picked. In the mapping report, the net between BUFG_1 and BUFG_2 is also classified as 'local' In FPGA editor I select the troublesome net between BUFG_1 and BUFG_2 and in the properties for the net I see that it is possible to set a priority. How can I insert such a priority into my ucf file so that P&R first routes the chain above and then take care of the clocks coming from the DCMs? Any idea? -- SvennArticle: 138245
I am working on a fairly large design, much larger than what I have previously implemented in an FPGA. I am wondering what is the best way to implement local reset circuits where they are needed. I've noticed in a lot of older XAPPs that an FF tree was used to handle the reset distribution. Also, what's the best way to go about making sure an enable signal does not have excessive fanout? In this case, it's an init_done signal from a DDR2 memory interface going to the rest of the design as an enable. Will the synthesis tools be smart enough to replicate registers for the signal to reduce fanout and speed up the design, or do I need to handle this myself in the VHDL? Thanks in advance for your advice / comments.Article: 138246
On Feb 10, 2:07=A0pm, uraniumore...@gmail.com wrote: > On Feb 9, 9:03=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > On Feb 9, 6:09=A0pm, uraniumore...@gmail.com wrote: > > > > On Feb 9, 1:36=A0am, Muzaffer Kal <k...@dspia.com> wrote: > > > > > On Mon, 9 Feb 2009 01:18:21 -0800 (PST), uraniumore...@gmail.com > > > > wrote: > > > > > >Does anyone know how I can generate a pulser of maximum repition r= ate > > > > >of 50 Mhz in verilog .. into my existing design ? I'd like to simu= late > > > > >this signal before I use the actual pulser into the board > > > > > I think you want a clock source. Here is one way you can generate i= t: > > > > > `timescale 1ns/100fs > > > > reg clk; > > > > initial > > > > begin > > > > =A0 =A0 =A0 =A0 pck =3D 0; > > > > =A0 =A0 =A0 =A0 forever clk =3D #10 ~clk; > > > > end > > > > > This clock toggles at 50 MHz as you want (ie 10ns high, 10 ns low) = and > > > > you can change the number 10 to your needs. > > > > Please note that this is only for testbench usage and you can't > > > > actually put this in your fpga. You have to use an oscillator on yo= ur > > > > board to generate a similar clock to drive into your fpga. > > > > > Muzaffer Kal > > > > > DSPIA INC. > > > > ASIC/FPGA Design Serviceshttp://www.dspia.com > > > > Hi, > > > > I was did make myself clear. I would like to have a variable pulesr, > > > maximum 50 Mhz. > > > > Thanks > > > I think you made something very clear. > > > Antti- Hide quoted text - > > > - Show quoted text - > > Okay, I made a grammatical blunder there! All jokes aside...I wanted > to know if there is some code out there that would generate a variable > pulse of max 50Mhz... > > thanks again, You need to supply more info about your "variable pulse", such as pulse width, duty cycle, and frequency. So for the high end (as someone else suggested) it sounds like you want 50MHz with 50% duty cycle (10ns HI / 10ns LO). -Dave PollumArticle: 138247
On Feb 10, 2:44 pm, jleslie48 <j...@jonathanleslie.com> wrote:
> On Feb 10, 1:17 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
> wrote:
>
>
>
> > On Tue, 10 Feb 2009 08:33:14 -0800 (PST), jleslie48 wrote:
> > > I think the next step is
> > >to update the goto functionality to be a goto LABEL instead of
> > >a PC location. So I think a good project is to add the
> > >'OP_LABEL [char]' mnemonic and re-tool the goto to
> > > walk through the ROM?? looking for the label.
>
> > Or, maybe, scan the ROM just once at startup, cacheing
> > the label addresses in a second blockRAM organized as
> > a table of PC values indexed by character.
>
> > It will still be a long way from Turing-completeness :-)
> > and a very long way from doing any useful DSP :-(
> > --
> > 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.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> > The contents of this message may contain personal views which
> > are not the views of Doulos Ltd., unless specifically stated.
>
> even better ;)
>
> but being able to scan a rom for specific signals, (label)
> and caching them you don't consider a worthwhile process of a
> DSP?
looking at the function contents, what is the purpose of this line:
constant p: t_ubyte_array (0 to pgm'length-1) := pgm;
in this context:
-- Function to convert the generic value into ROM-contents format
function contents(pgm: t_ubyte_array) return t_rom is
constant p: t_ubyte_array (0 to pgm'length-1) := pgm;
variable it: t_rom;
begin
it := (others => 0);
for iloop in p'range loop
it(iloop) := p(iloop);
end loop;
return it;
end;
It appears to me that constant 'p' is just a copy of pgm, what is
wrong
with just:
-- Function to convert the generic value into ROM-contents format
function contents(pgm: t_ubyte_array) return t_rom is
-- xxxxxxxxxx
variable it: t_rom;
begin
it := (others => 0);
for iloop in pgm'range loop
it(iloop) := pgm(iloop);
end loop;
return it;
end;
I tried it it synth's, implements and generates, but it doesn't run/
work, but why?
update;
this does work though:
-- Function to convert the generic value into ROM-contents format
function contents(pgm: t_ubyte_array) return t_rom is
--constant p: t_ubyte_array (0 to pgm'length-1) := pgm;
variable it: t_rom;
begin
it := (others => 0);
for iloop in 0 to pgm'length-1 loop
it(iloop) := pgm(iloop);
end loop;
return it;
end;
Article: 138248On Feb 10, 2:53=A0pm, Svenn Are Bjerkem <svenn.bjer...@googlemail.com> wrote: > Hi, > > for whatever reason not clear to me at this point, ISE-10.3 P&R use > two BUFGMUX each on oposite side of FPGA to route an incoming clock. > What I have is: > > Ext. clock =3D> IBUFG =3D> BUFG_1 =3D> BUFG_2 =3D> DCM_1/DCM_2/DCM3 > > IBUFG only drives BUFG_1 > BUFG_1 drives BUFG_2 and also a shift register in a synchronous reset > release > BUFG_2 drives three DCMs and nothing more. > > I inspect the work that P&R has done in FPGA editor: > IBUFG (replaced by the pad) and BUFG_1 are physically close and have > 0.03 ns delay > BUFG_1 and BUFG_2 are on opposite sides of FPGA and the connection is > routed on sub-optimal wiring according to the report file from ISE. > The delay is around 7 ns. I can verify this in FPGA editor, the wiring > goes zig-zag into boxes (probably switch facilities) on its way > between the two BUFGMUXes that the placer has picked. > In the mapping report, the net between BUFG_1 and BUFG_2 is also > classified as 'local' > > In FPGA editor I select the troublesome net between BUFG_1 and BUFG_2 > and in the properties for the net I see that it is possible to set a > priority. How can I insert such a priority into my ucf file so that > P&R first routes the chain above and then take care of the clocks > coming from the DCMs? > > Any idea? > > -- > Svenn What part are you using? For some parts, a global clock input can route to any BUFG and for other parts they can only route to BUFG on the same side of the die. The same goes for BUFG to DCM. Are you already using all the DCM's on the side of the die where your clock input comes in? Routing from the output of one BUFG to the input of another BUFG is very bad because it uses general fabric routing and can introduce jitter as well as delay to the clock net. This is especially bad if you are trying to drive a DCM. The best solution for this type of problem is to see if you can hand-place the DCM and BUFG components such that the clock stays on the same half of the die. Trying to direct the routing of your BUFG to BUFG net won't help much. In fact you may find that such a net must go all over the die because of the limited switch box locations that connect global clock nets to the fabric. For many parts such switch boxes are only located on the periphery of the die. Regards, GaborArticle: 138249
On Feb 10, 4:23 pm, jleslie48 <j...@jonathanleslie.com> wrote:
> On Feb 10, 2:44 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
>
>
> > On Feb 10, 1:17 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
> > wrote:
>
> > > On Tue, 10 Feb 2009 08:33:14 -0800 (PST), jleslie48 wrote:
> > > > I think the next step is
> > > >to update the goto functionality to be a goto LABEL instead of
> > > >a PC location. So I think a good project is to add the
> > > >'OP_LABEL [char]' mnemonic and re-tool the goto to
> > > > walk through the ROM?? looking for the label.
>
> > > Or, maybe, scan the ROM just once at startup, cacheing
> > > the label addresses in a second blockRAM organized as
> > > a table of PC values indexed by character.
>
> > > It will still be a long way from Turing-completeness :-)
> > > and a very long way from doing any useful DSP :-(
> > > --
> > > 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.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> > > The contents of this message may contain personal views which
> > > are not the views of Doulos Ltd., unless specifically stated.
>
> > even better ;)
>
> > but being able to scan a rom for specific signals, (label)
> > and caching them you don't consider a worthwhile process of a
> > DSP?
>
> looking at the function contents, what is the purpose of this line:
>
> constant p: t_ubyte_array (0 to pgm'length-1) := pgm;
>
> in this context:
>
> -- Function to convert the generic value into ROM-contents format
> function contents(pgm: t_ubyte_array) return t_rom is
> constant p: t_ubyte_array (0 to pgm'length-1) := pgm;
> variable it: t_rom;
> begin
> it := (others => 0);
> for iloop in p'range loop
> it(iloop) := p(iloop);
> end loop;
> return it;
> end;
>
> It appears to me that constant 'p' is just a copy of pgm, what is
> wrong
> with just:
>
> -- Function to convert the generic value into ROM-contents format
> function contents(pgm: t_ubyte_array) return t_rom is
> -- xxxxxxxxxx
> variable it: t_rom;
> begin
> it := (others => 0);
> for iloop in pgm'range loop
> it(iloop) := pgm(iloop);
> end loop;
> return it;
> end;
>
> I tried it it synth's, implements and generates, but it doesn't run/
> work, but why?
>
> update;
>
> this does work though:
> -- Function to convert the generic value into ROM-contents format
> function contents(pgm: t_ubyte_array) return t_rom is
> --constant p: t_ubyte_array (0 to pgm'length-1) := pgm;
> variable it: t_rom;
> begin
> it := (others => 0);
> for iloop in 0 to pgm'length-1 loop
> it(iloop) := pgm(iloop);
> end loop;
> return it;
> end;
another question, given 'the_program'
-- address....... 0 1 2 3 4 5 6 7 8 9
-- data (char)... 'T' '2' 'M' 'h' 'e' 'l' 'l' 'o' NUL NUL
-- data (byte)... 84 50 77 104 101 109 109 111 0 0
--
I'm not understanding the timing of events here:
-- Look at where our fetch/execute machine has got to.
case gen_state is
when init => -- Just come out of reset. Begin fetching
PC <= 0; -- from address 0.
reset_out <= '1';
gen_state <= do_reset; -- drive reset to other logic
halted <= '0';
tx_valid <= '0';
tx_data <= (others => '0');
delay_counter <= 5; -- reset interval
when do_reset => -- OK to start work now.
if timer = '1' then
if delay_counter = 0 then
reset_out <= '0';
gen_state <= new_PC; -- Give the ROM output time to
settle.
else
delay_counter <= delay_counter - 1;
end if;
end if;
when new_PC => -- PC has just changed. Next we will fetch the
gen_state <= fetch; -- instruction we have addressed....
PC <= PC + 1; -- and then increment PC ready for the next
read.
when fetch => -- The rom_data is now ready for us.
operation <= rom_data; -- Copy it into our operation
register.
gen_state <= decode; -- And move on to do a decode.
----------------------------------------------------------------------------------
after the gen_state finishes the delay_counter countdown,
its switches the gen_state to new_PC and the PC == 0.
on the next rising edge of the clock, the gen_state switches to
'fetch' and the PC increments to '1'
on the next clock pulse, the gen_state is fetch and it tries
to set the operation to the rom_data, specifically, the_rom(1)
which is not an operation at all, but rather the data value of the
operation declared in the_rom(0).
Now I know I got something wrong, because this works, but my
'stepping through' the code implies to me that the PC increment
that is part of the fetch will jump over the operation to the
operations
data.
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