Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 137100

Article: 137100
Subject: bitstream protection
From: kharray.bassas@gmail.com
Date: Tue, 23 Dec 2008 02:27:42 -0800 (PST)
Links: << >>  << T >>  << A >>
Good evening folks,

 I m studying the different ways adopted by altera xilinx and lattice
to secure bitstream.
 As a priori knowledge , XILINX (virtex5) method is the most efficient
but i still have some questions about this.

=> When the decryptor start to run ? after receiving the first
configurable data (written to FDRI register)  ? or after verifying the
ECC of the first frame ?

=> if an encrypted bitstream is loaded to FPGA with a wrong key, the
decryptor starts to run anyway ?

=> there is no other solution to replace the backup battery ?

Thank you .

Article: 137101
Subject: Re: Adding userports to a custom peripheral in XPS
From: Lorenz Kolb <lorenz.kolb@uni-ulm.de>
Date: Tue, 23 Dec 2008 13:20:12 +0100
Links: << >>  << T >>  << A >>
Jan wrote:
> Dear All,
> 
> I'm trying to make a peripheral in XPS. I've used the "Create or Import 
> Peripheral" wizard to create the peripheral.
> I can also get the thing to compile and I also successfully added the IP 
> to my MicroBlaze design.
> 
> However, now I want to add more advanced stuff to the peripheral and 
> therefor need to add userports. I just don't know how to do it. I have 
> added some ports in the IP Entity and also added them in the MPD file.
> 
> But still nothing shows in the "System Assembly View" when I add the IP. 
> Only the ports that was already there.
> 

You might also want to "Project -> Rescan User Repositories"

To force EDK to update the information coming from the changed .mpd.

Regards,

Lorenz

Article: 137102
Subject: DFFR using DFF (only, may be extra gates)
From: santhosh_h_98@yahoo.com
Date: Tue, 23 Dec 2008 04:57:21 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

I know DFF is:

module DFF(d,clk,q) ;
     input d, clk ;
     output reg q ;

     always @(posedge clk)
           q<= d ;
endmodule

Now I need to implement ASYNCHRONOUS RESET flip flop
using DFF ONLY, may be some extract logic. HOW CAN I DO THAT ?

The implemented circuit MUST WORK AS FOLLOWS:

module DFFR(d,clk,r, q) ;
     input d, clk,r ;
     output reg q ;

     always @(posedge clk or posedge r)
          if (r) q <= 0 ;
          else  q<= d ;
endmodule

Please give the code or diagram. I am curious about this.

Sant

Article: 137103
Subject: which HLL for HPC applications implementation?
From: Karl <karl.polytech@googlemail.com>
Date: Tue, 23 Dec 2008 06:18:30 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,
I have to map some scientific application algorithms on FPGA using a
High Level Language (HLL) and not VHDL. I am lost regarding the choice
of the HLL language to use which not only allows efficient mapping but
also the user to alter and enhance the compiler and the mapping in
general, preferably open source compiler!

I got conflicting feedbacks about Mitrion-C in particular which i was
using to use. some suggested Handel-C other Mitrion-C, etc...i could
not find a rigourous comparative studies. could you share your
experience with us and/or any advice

Cheers,

Article: 137104
Subject: Re: DFFR using DFF (only, may be extra gates)
From: Lorenz Kolb <lorenz.kolb@uni-ulm.de>
Date: Tue, 23 Dec 2008 17:54:58 +0100
Links: << >>  << T >>  << A >>
santhosh_h_98@yahoo.com wrote:
> Hi,
> 
> I know DFF is:
> 
> module DFF(d,clk,q) ;
>      input d, clk ;
>      output reg q ;
> 
>      always @(posedge clk)
>            q<= d ;
> endmodule
> 
> Now I need to implement ASYNCHRONOUS RESET flip flop
> using DFF ONLY, may be some extract logic. HOW CAN I DO THAT ?
> 
> The implemented circuit MUST WORK AS FOLLOWS:
> 
> module DFFR(d,clk,r, q) ;
>      input d, clk,r ;
>      output reg q ;
> 
>      always @(posedge clk or posedge r)
>           if (r) q <= 0 ;
>           else  q<= d ;
> endmodule
> 
> Please give the code or diagram. I am curious about this.
> 

Well actually that'll cost logic in the clock path. You'll most likely 
have to create an own clock clk_dffr which is clk or rst; and you'll 
need d_dffr which will be d and not rst.

That should solve the task (though I'm not happy about that solution, 
but no better one came to my mind).

> Sant

Regards,

Lorenz

Article: 137105
Subject: Re: Adding userports to a custom peripheral in XPS
From: Jan <1@2.3>
Date: Tue, 23 Dec 2008 17:59:39 +0100
Links: << >>  << T >>  << A >>
jeremywwebb@gmail.com wrote:
> On Dec 22, 2:07 pm, Jan <1...@2.3> wrote:
>> However, now I want to add more advanced stuff to the peripheral and
>> therefor need to add userports. I just don't know how to do it. I have
>> added some ports in the IP Entity and also added them in the MPD file.
>>
>> But still nothing shows in the "System Assembly View" when I add the IP.
>> Only the ports that was already there.

> Did you add the PORT(s) to your IP instance in the MHS file? If you
> don't add the PORT(s) to the IP instance in the MHS file, then they
> won't show up in the "Ports" tab in XPS. Another way to get the ports
> to show up is to re-import the IP in XPS. This will only work if
> you've added the ports in the top-level IP HDL file and the MPD file.

Ok, after trying to add the port in the MHS file it showed up in the 
assembly view. Now a new problem appeared. I don't know how to map the 
new port to a physical port. Where can I add new locations that then can 
be selected in the assembly view?

Regards
   Jan

Article: 137106
Subject: Re: Bit width in CPU cores
From: rickman <gnuarm@gmail.com>
Date: Tue, 23 Dec 2008 09:07:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 23, 4:46 am, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >Actually, this is a potential paid app, but is not likely to be the
> >first.  The first is going to be part of a test fixture for the
> >modules which are currently being built for the time code signal app.
> >There may be some character processing, but not much.  However, I
> >don't want to hamstring later apps and I prefer to make the processor
> >as flexible as practical now.
>
> You don't have to make it "the" processor.  You can tweak the
> instruction set for each application.  That's probably not
> worth the effort, but it might be critical for some application.
>
> (I'm assuming you are writing small chunks of code rather than
> large things like operating systems or compilers.)
>
> A couple of ideas to add to your bag of tricks...
>
> You can get constants from a ROM.  So a load-immediate of a big
> number (16 bits) doesn't take 3 bytes of instruction.  It's one
> byte of instruction and a couple of bytes in another ROM.
> That assumes you have enough bits in the instruction to do
> a table lookup.

Actually, it only takes two 9 bit instructions to provide a 16 bit
literal on the return stack.  It takes another 9 bit instruction to
move it to the data stack.  Your approach uses two bytes for the data
and a byte for the instruction.  How is that a savings?  If you
consider the potential wasted space from breaking the program space
into a lookup table and code space, I don't see how this would be at
all useful.

In Koopman's code analysis, the instruction at the top of each list
was the CALL (which needs an address constant).  LIT was number 2 on
the static list and 5 on the dynamic list.  VARIABLE and 0BRANCH were
high up in the list too.  So the instruction I optimized the most was
RLIT which uses 1 bit to specify the instruction and the remaining
bits as data.  The RLIT instruction sets a flag so that the first RLIT
pushes its data on the stack.  Subsequent RLIT instructions shift
their data into the stack to build longer constants.  Any other
instruction clears the literal flag.  I don't think you can get much
better than this for constant data.


> In the old days, instruction sets like this were implemented
> with microcode.  One hack that gives you a lot of flexibility
> is to do a dispatch on the op-code.  That lets you use
> fractional-bits for various fields.  Say you have 3
> opcodes that all want 10 different values for immediate/constants.
> You don't have to round up to 16 values,  That would take
> 4x16 slots.  Instead, you can do a table lookup (ROM again)
> on the op-code and pack them into 30 slots.  That may cost
> you a pipeline cycle.
>
> ROMs are handy for opcode decoding.  Take your 8 or 9 bits
> (or part of them) and feed that into a wide ROM that gives
> you all the decoded control signals you need.  This is sliding
> toward the microcode way of thinking.

That sounds nice, but a ROM in an FPGA uses the sync RAM blocks.  They
require a clock edge to produce an output and most of the delay is on
the output side.  This is pathologically slow for use as microcode.
Also block RAMs can be a precious resource.  Although ROMs may seem
like a good idea, that is just an implementation detail and is best
left to the later stages of planning.  This will have nothing to do
with designing an instruction set.  BTW, microcode really shines when
you are designing a machine with lots of states.  My CPU has one
state, "Decode / Execute&Fetch".  The decode is done first and the
execute and fetch are done in parallel, all in the same clock cycle.
There are no states, it just continues to update the instruction
pointer and register on each clock cycle and the rest of the chip
functions according to what is in the instruction register.


> I still think the most important thing you should do is write
> lots of code so you have some samples to feed to the tools
> and get some real numbers.

I agree, but I was hoping to find code rather than having to write it
first.  Maybe you are right and instead of working on the CPU, I
should start writing code and working on the tools for that.

Rick

Article: 137107
Subject: Re: Adding userports to a custom peripheral in XPS
From: Lorenz Kolb <lorenz.kolb@uni-ulm.de>
Date: Tue, 23 Dec 2008 18:08:12 +0100
Links: << >>  << T >>  << A >>
Jan wrote:
> jeremywwebb@gmail.com wrote:

> Ok, after trying to add the port in the MHS file it showed up in the 
> assembly view. Now a new problem appeared. I don't know how to map the 
> new port to a physical port. Where can I add new locations that then can 
> be selected in the assembly view?

Either the texteditor-way:

(Edit .ucf and .mhs by hand) or the official way: edit .ucf and  create 
an external port (by mind i'd say there is a button in the right upper 
corner of the system assembly view (ports tab))

Alternatively You can click on the peripheral's port and get a 
drop-down-combo where you can click on "make external".

> 
> Regards
>   Jan

Regards,

Lorenz

Article: 137108
Subject: Re: DFFR using DFF (only, may be extra gates)
From: Gabor <gabor@alacron.com>
Date: Tue, 23 Dec 2008 09:30:05 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 23, 11:54=A0am, Lorenz Kolb <lorenz.k...@uni-ulm.de> wrote:
> santhosh_h...@yahoo.com wrote:
> > Hi,
>
> > I know DFF is:
>
> > module DFF(d,clk,q) ;
> > =A0 =A0 =A0input d, clk ;
> > =A0 =A0 =A0output reg q ;
>
> > =A0 =A0 =A0always @(posedge clk)
> > =A0 =A0 =A0 =A0 =A0 =A0q<=3D d ;
> > endmodule
>
> > Now I need to implement ASYNCHRONOUS RESET flip flop
> > using DFF ONLY, may be some extract logic. HOW CAN I DO THAT ?
>
> > The implemented circuit MUST WORK AS FOLLOWS:
>
> > module DFFR(d,clk,r, q) ;
> > =A0 =A0 =A0input d, clk,r ;
> > =A0 =A0 =A0output reg q ;
>
> > =A0 =A0 =A0always @(posedge clk or posedge r)
> > =A0 =A0 =A0 =A0 =A0 if (r) q <=3D 0 ;
> > =A0 =A0 =A0 =A0 =A0 else =A0q<=3D d ;
> > endmodule
>
> > Please give the code or diagram. I am curious about this.
>
> Well actually that'll cost logic in the clock path. You'll most likely
> have to create an own clock clk_dffr which is clk or rst; and you'll
> need d_dffr which will be d and not rst.
>
> That should solve the task (though I'm not happy about that solution,
> but no better one came to my mind).
>
> > Sant
>
> Regards,
>
> Lorenz

Even then you would need to ensure adequate setup time on the D
input when resetting.  Assuming D was otherwise high, d_dffr and
clk_dffr would change at the same time unless you made extra delay
in the clock path.  And of course you need to make sure that
your path from the standard D input still has hold time after
all of the gating...

Good luck,
Gabor

Article: 137109
Subject: Re: which HLL for HPC applications implementation?
From: rickman <gnuarm@gmail.com>
Date: Tue, 23 Dec 2008 10:10:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 23, 9:18=A0am, Karl <karl.polyt...@googlemail.com> wrote:
> Hi,
> I have to map some scientific application algorithms on FPGA using a
> High Level Language (HLL) and not VHDL. I am lost regarding the choice
> of the HLL language to use which not only allows efficient mapping but
> also the user to alter and enhance the compiler and the mapping in
> general, preferably open source compiler!
>
> I got conflicting feedbacks about Mitrion-C in particular which i was
> using to use. some suggested Handel-C other Mitrion-C, etc...i could
> not find a rigourous comparative studies. could you share your
> experience with us and/or any advice

I am curious about what you are planning to do.  When you talk about
altering the "mapping" what does that mean?  If you are looking to use
an algorithm written in C as source code for an FPGA design, I don't
know that adjusting the "mapping" is going to work for you.

Typically an algorithm has to be ported to an FPGA.  If the algorithm
is written starting with the idea of using it in an FPGA then the code
may compile ok.  But if it was not, it is unlikely to be compilable at
all or at best produce an inefficient design.

Software is normally written to be executed sequentially on a
processor.  FPGAs can also do that, but for the most part they provide
parallel execution on dedicated hardware.  To efficiently design in an
FPGA this difference needs to be addressed and computers are not very
good at doing this yet.  A designer is best for that job.

BTW, you didn't explain what HPC stands for.  I know what HPLC is.

Rick

Article: 137110
Subject: Re: DFFR using DFF (only, may be extra gates)
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Tue, 23 Dec 2008 18:20:50 +0000
Links: << >>  << T >>  << A >>
>> > Now I need to implement ASYNCHRONOUS RESET flip flop
>> > using DFF ONLY, may be some extract logic. HOW CAN I DO THAT ?
>>
>> > The implemented circuit MUST WORK AS FOLLOWS:
>>
>> > module DFFR(d,clk,r, q) ;
>> >      input d, clk,r ;
>> >      output reg q ;
>>
>> >      always @(posedge clk or posedge r)
>> >           if (r) q <= 0 ;
>> >           else  q<= d ;
>> > endmodule
>>
>> > Please give the code or diagram. I am curious about this.

The thing I'm curious about is WHY?

Gabor is right about the extreme difficulty of getting 
something that works correctly if you try to gate reset
and clock together.

If you're allowed any amount of combinational logic
in addition to DFF, which I assume is the case, then
you could consider this idea, (c)2008 Santa's Elves, 
to be enjoyed in moderation with a vomit-bag handy:

module DFFR(input d, clk, r, output q);
  //
  wire d_int, q_int, flipper;
  //
  // Here's the main FF.  Its output is inverted
  // if necessary to give reset behaviour.
  DFF data_ff(.d(d_int), .clk(clk), .q(q_int));
  assign q = q_int ^ flipper;
  //
  // The second FF captures the data FF's output
  // when reset happens, and uses that captured
  // value to invert the main FF's output if necessary.
  DFF flipper_ff(.d(q_int), .clk(r), .q(flipper);
  //
  // Finally, we invert the D input to the main FF
  // to match the inversion of its output.  But we 
  // also disable clocking of this FF while reset
  // is active, so that we don't need to worry about
  // the reset value at any time other than (posedge r).
  assign d_int = r? q_int: d ^ flipper;
  //
endmodule

This is still exposed to a race between active edges
of clock and reset, but otherwise I think it works;
and it doesn't corrupt the hold time behaviour of the
main (data_ff) flop.

Actually, on mature reflection I think this one is
(c)2008 The Grinch.

Season's Greetings to all :-)
-- 
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: 137111
Subject: Re: DFFR using DFF (only, may be extra gates)
From: gabor <gabor@alacron.com>
Date: Tue, 23 Dec 2008 11:12:45 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 23, 1:20=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> >> > Now I need to implement ASYNCHRONOUS RESET flip flop
> >> > using DFF ONLY, may be some extract logic. HOW CAN I DO THAT ?
>
> >> > The implemented circuit MUST WORK AS FOLLOWS:
>
> >> > module DFFR(d,clk,r, q) ;
> >> > =A0 =A0 =A0input d, clk,r ;
> >> > =A0 =A0 =A0output reg q ;
>
> >> > =A0 =A0 =A0always @(posedge clk or posedge r)
> >> > =A0 =A0 =A0 =A0 =A0 if (r) q <=3D 0 ;
> >> > =A0 =A0 =A0 =A0 =A0 else =A0q<=3D d ;
> >> > endmodule
>
> >> > Please give the code or diagram. I am curious about this.
>
> The thing I'm curious about is WHY?
>
> Gabor is right about the extreme difficulty of getting
> something that works correctly if you try to gate reset
> and clock together.
>
> If you're allowed any amount of combinational logic
> in addition to DFF, which I assume is the case, then
> you could consider this idea, (c)2008 Santa's Elves,
> to be enjoyed in moderation with a vomit-bag handy:
>
> module DFFR(input d, clk, r, output q);
> =A0 //
> =A0 wire d_int, q_int, flipper;
> =A0 //
> =A0 // Here's the main FF. =A0Its output is inverted
> =A0 // if necessary to give reset behaviour.
> =A0 DFF data_ff(.d(d_int), .clk(clk), .q(q_int));
> =A0 assign q =3D q_int ^ flipper;
> =A0 //
> =A0 // The second FF captures the data FF's output
> =A0 // when reset happens, and uses that captured
> =A0 // value to invert the main FF's output if necessary.
> =A0 DFF flipper_ff(.d(q_int), .clk(r), .q(flipper);
> =A0 //
> =A0 // Finally, we invert the D input to the main FF
> =A0 // to match the inversion of its output. =A0But we
> =A0 // also disable clocking of this FF while reset
> =A0 // is active, so that we don't need to worry about
> =A0 // the reset value at any time other than (posedge r).
> =A0 assign d_int =3D r? q_int: d ^ flipper;
> =A0 //
> endmodule
>
> This is still exposed to a race between active edges
> of clock and reset, but otherwise I think it works;
> and it doesn't corrupt the hold time behaviour of the
> main (data_ff) flop.
>
> Actually, on mature reflection I think this one is
> (c)2008 The Grinch.
>
> Season's Greetings to all :-)
> --
> 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.

Wow!  My head is spinning!

It seems to me if you want to use the gated Q approach, you
don't really need a "flipper" but only an AND gate since
reset can only drive the Q output low.  If you made an
internal reset signal, on while "r" is asserted and
held until the data flip-flop Q output is low, you can
gate this into the d input of the data flip-flop as
a synchronous reset, and also gate it with Q to make the
reset appear asynchronous.  You wouldn't need a proper
D flip-flop for the reset signal, just an implied
latch like:

r_int =3D r | r_int & q_int;

then

d_int =3D d & !r_int;

q =3D q_int & !r_int;

Cheers,
Gabor

Article: 137112
Subject: Re: EDK map error 1492 - incompatible programming error
From: Gabor <gabor@alacron.com>
Date: Tue, 23 Dec 2008 11:15:54 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 23, 1:50=A0am, "Andrew W. Hill" <aquaregi...@gmail.com> wrote:
> All,
> I'm using EDK 10.1, specced for the ML501. =A0When I reach the mapping
> phase, I get the following error (several times):
>
> ERROR:PhysDesignRules:1492 - Incompatible programming for comp
> mb_plb_M_ABus<1>.
> =A0 =A0The pair of luts SLICEL_A5LUT and SLICEL_A6LUT must have a
> compatible
> =A0 =A0equation, lower bits must be programmed the same. The SLICEL_A5LUT
> hex
> =A0 =A0equation is <O5=3D0x08080808> and the SLICEL_A6LUT hex equation is
> =A0 =A0<O6=3D0x607AA67800008888>.
>
> I found the following Xilinx note on the error, which notes that this
> error was erroneously thrown in EDK versions <8 :http://www.xilinx.com/su=
pport/answers/23645.htm
>
> My system is fairly standard. =A0I used BSB and added a few things
> (LEDs,switches), but nothing particularly exotic. Is there something
> obvious that I might have missed, or is this likely to be an error
> with DRC?
>
> Thanks
> Andrew

The obvious question, given the note from Xilinx, is did you ever
build
any part of this system under an older revision of EDK?  Xilinx
software
is famous for failing to clean up old bits of object...

Article: 137113
Subject: Re: DFFR using DFF (only, may be extra gates)
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Tue, 23 Dec 2008 13:37:37 -0600
Links: << >>  << T >>  << A >>
I
>Gabor is right about the extreme difficulty of getting 
>something that works correctly if you try to gate reset
>and clock together.
>
>If you're allowed any amount of combinational logic
>in addition to DFF, which I assume is the case, then
>you could consider this idea, (c)2008 Santa's Elves, 
>to be enjoyed in moderation with a vomit-bag handy:

If you have unlimited gates, why not just ignore the DFF?

Old data books gave gate level diagrams for things
like FFs.  Here is an example:
  http://focus.ti.com/lit/ds/symlink/sn74ls74a.pdf

An edge triggered FF is two latches.  A latch is
a pair of cross coupled gates.  Set/Reset are just
another term into some of the gates.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 137114
Subject: Re: EDK map error 1492 - incompatible programming error
From: "Andrew W. Hill" <aquaregia27@gmail.com>
Date: Tue, 23 Dec 2008 11:43:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 23, 11:15 am, Gabor <ga...@alacron.com> wrote:
> On Dec 23, 1:50 am, "Andrew W. Hill" <aquaregi...@gmail.com> wrote:
> > I'm using EDK 10.1, specced for the ML501.  When I reach the mapping
> > phase, I get the following error (several times):
>
> > ERROR:PhysDesignRules:1492 - Incompatible programming for comp
> > mb_plb_M_ABus<1>.
> >    The pair of luts SLICEL_A5LUT and SLICEL_A6LUT must have a
> > compatible
> >    equation, lower bits must be programmed the same. The SLICEL_A5LUT
> > hex
> >    equation is <O5=0x08080808> and the SLICEL_A6LUT hex equation is
> >    <O6=0x607AA67800008888>.
>
> > I found the following Xilinx note on the error, which notes that this
> > error was erroneously thrown in EDK versions <8 :http://www.xilinx.com/support/answers/23645.htm
>
> > My system is fairly standard.  I used BSB and added a few things
> > (LEDs,switches), but nothing particularly exotic. Is there something
> > obvious that I might have missed, or is this likely to be an error
> > with DRC?
>
> The obvious question, given the note from Xilinx, is did you ever
> build
> any part of this system under an older revision of EDK?  Xilinx
> software
> is famous for failing to clean up old bits of object...

I previously built under EDK 9, but I did a clean from within EDK and
also did a quick walkthrough of the remaining files. I've never built
it in EDK <8.
Cheers
Andrew

Article: 137115
Subject: Re: DFFR using DFF (only, may be extra gates)
From: Muzaffer Kal <kal@dspia.com>
Date: Tue, 23 Dec 2008 12:19:34 -0800
Links: << >>  << T >>  << A >>
On Tue, 23 Dec 2008 18:20:50 +0000, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

>This is still exposed to a race between active edges
>of clock and reset, but otherwise I think it works;
>and it doesn't corrupt the hold time behaviour of the
>main (data_ff) flop.

How is this any different from a DFFR ie a DFF with built-in async
reset? One has to meet the reset removal timing in a DFFR which is the
same problem with your solution above.

Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com

Article: 137116
Subject: Re: DFFR using DFF (only, may be extra gates)
From: Muzaffer Kal <kal@dspia.com>
Date: Tue, 23 Dec 2008 12:25:07 -0800
Links: << >>  << T >>  << A >>
On Tue, 23 Dec 2008 11:12:45 -0800 (PST), gabor <gabor@alacron.com>
wrote:

>It seems to me if you want to use the gated Q approach, you
>don't really need a "flipper" but only an AND gate since
>reset can only drive the Q output low.  If you made an
>internal reset signal, on while "r" is asserted and
>held until the data flip-flop Q output is low, you can
>gate this into the d input of the data flip-flop as
>a synchronous reset, and also gate it with Q to make the
>reset appear asynchronous.  You wouldn't need a proper
>D flip-flop for the reset signal, just an implied
>latch like:
>
>r_int = r | r_int & q_int;
>
>then
>
>d_int = d & !r_int;
>
>q = q_int & !r_int;

This doesn't solve the problem perfectly. A real async reset flop
doesn't need a clock edge to reset the internal state of the flop so
if a reset arrives and leaves before any clock edges appear the Q of
the flop changes to and stays at 0. In the case above the you have no
control over q_int which is presumably X in this condition so when you
remove reset q will go back to X which is what the async reset was
trying to solve after all.

Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com

Article: 137117
Subject: Re: DFFR using DFF (only, may be extra gates)
From: Gabor <gabor@alacron.com>
Date: Tue, 23 Dec 2008 12:46:45 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 23, 3:25=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> On Tue, 23 Dec 2008 11:12:45 -0800 (PST), gabor <ga...@alacron.com>
> wrote:
>
>
>
> >It seems to me if you want to use the gated Q approach, you
> >don't really need a "flipper" but only an AND gate since
> >reset can only drive the Q output low. =A0If you made an
> >internal reset signal, on while "r" is asserted and
> >held until the data flip-flop Q output is low, you can
> >gate this into the d input of the data flip-flop as
> >a synchronous reset, and also gate it with Q to make the
> >reset appear asynchronous. =A0You wouldn't need a proper
> >D flip-flop for the reset signal, just an implied
> >latch like:
>
> >r_int =3D r | r_int & q_int;
>
> >then
>
> >d_int =3D d & !r_int;
>
> >q =3D q_int & !r_int;
>
> This doesn't solve the problem perfectly. A real async reset flop
> doesn't need a clock edge to reset the internal state of the flop so
> if a reset arrives and leaves before any clock edges appear the Q of
> the flop changes to and stays at 0. In the case above the you have no
> control over q_int which is presumably X in this condition so when you
> remove reset q will go back to X which is what the async reset was
> trying to solve after all.
>
> Muzaffer Kal
>
> DSPIA INC.
> ASIC/FPGA Design Serviceshttp://www.dspia.com

Well actually that is why r_int is held until q_int goes
low.  This guarantees that the next clock edge after reset
also clocks the Q low.  The down side to this of course
is that it doesn't actually model a D flip-flop with
async reset, which could possibly go high on the first
edge after reset is released.

Article: 137118
Subject: Re: DFFR using DFF (only, may be extra gates)
From: Muzaffer Kal <kal@dspia.com>
Date: Tue, 23 Dec 2008 14:10:26 -0800
Links: << >>  << T >>  << A >>
On Tue, 23 Dec 2008 12:46:45 -0800 (PST), Gabor <gabor@alacron.com>
wrote:
>On Dec 23, 3:25 pm, Muzaffer Kal <k...@dspia.com> wrote:
>> On Tue, 23 Dec 2008 11:12:45 -0800 (PST), gabor <ga...@alacron.com>
>> wrote:
>>
>>
>>
>> >It seems to me if you want to use the gated Q approach, you
>> >don't really need a "flipper" but only an AND gate since
>> >reset can only drive the Q output low.  If you made an
>> >internal reset signal, on while "r" is asserted and
>> >held until the data flip-flop Q output is low, you can
>> >gate this into the d input of the data flip-flop as
>> >a synchronous reset, and also gate it with Q to make the
>> >reset appear asynchronous.  You wouldn't need a proper
>> >D flip-flop for the reset signal, just an implied
>> >latch like:
>>
>> >r_int = r | r_int & q_int;
>>
>> >then
>>
>> >d_int = d & !r_int;
>>
>> >q = q_int & !r_int;
>>
>> This doesn't solve the problem perfectly. A real async reset flop
>> doesn't need a clock edge to reset the internal state of the flop so
>> if a reset arrives and leaves before any clock edges appear the Q of
>> the flop changes to and stays at 0. In the case above the you have no
>> control over q_int which is presumably X in this condition so when you
>> remove reset q will go back to X which is what the async reset was
>> trying to solve after all.
>>
>> Muzaffer Kal
>>
>> DSPIA INC.
>> ASIC/FPGA Design Services
>> http://www.dspia.com
>
>Well actually that is why r_int is held until q_int goes
>low.  This guarantees that the next clock edge after reset
>also clocks the Q low.  The down side to this of course
>is that it doesn't actually model a D flip-flop with
>async reset, which could possibly go high on the first
>edge after reset is released.

I think the down side is a little more than that. If q_int is X (which
is what one should expect for a flop with no async controls),  
"r_int & q_int" is also X. So when r goes high then low, r_int is 1
then X. I don't think you're getting the latching affect you're
looking for; in Verilog simulation anyway.
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com

Article: 137119
Subject: Re: DFFR using DFF (only, may be extra gates)
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Tue, 23 Dec 2008 22:46:22 +0000
Links: << >>  << T >>  << A >>
On Tue, 23 Dec 2008 12:19:34 -0800, Muzaffer Kal <kal@dspia.com>
wrote:

>On Tue, 23 Dec 2008 18:20:50 +0000, Jonathan Bromley wrote:
>
>>This 

[...devil's-spawn I proposed for a DFFR made only from
DFFs and gates]

>>is still exposed to a race between active edges
>>of clock and reset
>
>How is this any different from a DFFR ie a DFF with built-in async
>reset? One has to meet the reset removal timing in a DFFR which is the
>same problem with your solution above.

The problem isn't removal/recovery.  It's at the *assertion* 
of reset, when the "flipper" DFF captures the current state 
of the data FF.  If the data FF changes state at the same 
time, thanks to a simultaneous clock edge, the flipper can
hold the wrong value and the whole mess might reset to 1 
instead of 0.  A conventional DFFR model doesn't suffer 
from such a race, and nor does the real thing.

It's easy to fix by introducing a non-zero time delay in 
the clock path to the flipper DFF's clock.  But then the 
whole thing could fail if there's a reset pulse shorter
than that time delay.  I don't think there is any way out 
that is completely bombproof.

Of course, as someone else pointed out, you can do the whole
thing with a gate-level model of a master-slave flip-flop,
or something similar.  I didn't feel that was in the spirit
of the original rather bizarre question, so provided instead
my correspondingly bizarre solution.  I still think it goes
rather well with the mince pies, plum pudding and other 
general Yuletide excesses:
On the first day of Christmas my client sent to me
  a skew-ridden gated clock tree.
On the second day of Christmas my client sent to me
  two setup failures and a skew-ridden gated clock tree.
On the third day....
  bah, humbug, you get the general idea.
-- 
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: 137120
Subject: Re: DFFR using DFF (only, may be extra gates)
From: Muzaffer Kal <kal@dspia.com>
Date: Tue, 23 Dec 2008 15:15:00 -0800
Links: << >>  << T >>  << A >>
On Tue, 23 Dec 2008 22:46:22 +0000, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

>On Tue, 23 Dec 2008 12:19:34 -0800, Muzaffer Kal <kal@dspia.com>
>wrote:
>
>>On Tue, 23 Dec 2008 18:20:50 +0000, Jonathan Bromley wrote:
>>
>>>This 
>
>[...devil's-spawn I proposed for a DFFR made only from
>DFFs and gates]
>
>>>is still exposed to a race between active edges
>>>of clock and reset
>>
>>How is this any different from a DFFR ie a DFF with built-in async
>>reset? One has to meet the reset removal timing in a DFFR which is the
>>same problem with your solution above.
>
>The problem isn't removal/recovery.  It's at the *assertion* 
>of reset, when the "flipper" DFF captures the current state 
>of the data FF.  If the data FF changes state at the same 
>time, thanks to a simultaneous clock edge, the flipper can
>hold the wrong value and the whole mess might reset to 1 
>instead of 0.  A conventional DFFR model doesn't suffer 
>from such a race, and nor does the real thing.

Actually I think there is another issue with the model. It is possible
that the reset will start high at the start of the simulation and
there won't be a posedge for the flipper flop to see. I am not sure if
the model handles that case correctly.

Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com

Article: 137121
Subject: Re: which HLL for HPC applications implementation?
From: Karl <karl.polytech@googlemail.com>
Date: Tue, 23 Dec 2008 16:27:45 -0800 (PST)
Links: << >>  << T >>  << A >>
Thanks Rick for your reply. Sorry for not being so clear. HPC was a
reference to High Performance Computing. I want to use a high level
language to implement some legacy codes: common HPC packages (e.g.
numerical libraries, statistical packages) and specialised software
(e.g. in computational biology) on FPGA. I want to investigate how
good FPGA can be in implementing floating point based algorithms as
well as doing some research in hardware compilation. as such i want to
use a high level language which permits the integration of some add-in
by the developer (that;s why i said a language which allows the user
to improve on the mapping of the algorithms on FPGA) as i know these
high level languages are not yet too efficient and don't want to be
bound by their current limitations. what language could be best? what
about xilinx Chimps?

Cheers



Article: 137122
Subject: Re: which HLL for HPC applications implementation?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 24 Dec 2008 02:48:58 +0000 (UTC)
Links: << >>  << T >>  << A >>
Karl <karl.polytech@googlemail.com> wrote:
> Thanks Rick for your reply. Sorry for not being so clear. HPC was a
> reference to High Performance Computing. I want to use a high level
> language to implement some legacy codes: common HPC packages (e.g.
> numerical libraries, statistical packages) and specialised software
> (e.g. in computational biology) on FPGA. 

Most computational biology is done fixed point, which works
very well in FPGAs.  Floating point tends to take up a lot of
space in an FPGA, especially the normalization logic needed for
addition.  In many cases adders are bigger than multipliers.

> I want to investigate how
> good FPGA can be in implementing floating point based algorithms as
> well as doing some research in hardware compilation. as such i want to
> use a high level language which permits the integration of some add-in
> by the developer (that;s why i said a language which allows the user
> to improve on the mapping of the algorithms on FPGA) as i know these
> high level languages are not yet too efficient and don't want to be
> bound by their current limitations. what language could be best? what
> about xilinx Chimps?

The systolic array architecture is often used for FPGA based algorithms,
in both fixed and floating point.  

-- glen

Article: 137123
Subject: Re: which HLL for HPC applications implementation?
From: rickman <gnuarm@gmail.com>
Date: Tue, 23 Dec 2008 21:09:35 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 23, 7:27 pm, Karl <karl.polyt...@googlemail.com> wrote:
> Thanks Rick for your reply. Sorry for not being so clear. HPC was a
> reference to High Performance Computing. I want to use a high level
> language to implement some legacy codes: common HPC packages (e.g.
> numerical libraries, statistical packages) and specialised software
> (e.g. in computational biology) on FPGA. I want to investigate how
> good FPGA can be in implementing floating point based algorithms as
> well as doing some research in hardware compilation. as such i want to
> use a high level language which permits the integration of some add-in
> by the developer (that;s why i said a language which allows the user
> to improve on the mapping of the algorithms on FPGA) as i know these
> high level languages are not yet too efficient and don't want to be
> bound by their current limitations. what language could be best? what
> about xilinx Chimps?

I think what I said before still applies.  You have algorithms written
in a software language.  Most software programming languages are
designed for sequential processing.  I expect all of your code is
written in this manner.  An FPGA does not do anything better than a
processor can do, in fact they are typically slower in any given
activity.  But while a processor executes the steps sequentially an
FPGA can perform things in parallel.  If you code an FFT butterfly,
for example, it uses multiple complex multiplies and adds.  A
processor has to do each step sequentially.  A specialized processor
can perform a couple of multiplies and adds simultaneously, but the
algorithm is still sequential.  An FPGA can be programmed to do all
the steps at the same time to produce a butterfly result on each clock
cycle.  Or you can even build multiple butterfly units to perform many
butterflies in parallel.  Or an FPGA can be programmed to perform the
FFT and the FIR filter in parallel and so on.

Here is the "BUT": HDL is short for hardware description language.
Notice it is *not* called a programming language.  That is because you
are not programming a processor.  You are describing the hardware that
will do the processing.  There is a big difference.

I am not overly familiar with designing hardware in the C language,
but from what I have read, C is not used as an HDL in the same way as
it is to write a program.  The coding style has to use a specific
structure that can be recognized and translated into hardware.

So if you want to use a C compiler or Verilog or VHDL, you need to
understand that you can't just take a software program and have a tool
turn it into hardware.  At least I don't think you can.  I also am
pretty sure that you can't easily write an add-in to make this
translation.  Doing so would be such a significant advance that it
would have been done by now.

Please don't let my words be a wet blanket to your ideas.  I am just
trying to present the current state of the tools realistically.  If
the point of your research is to develop advanced tools, then by all
means proceed.  But if your goal is to port HPC programs to FPGAs,
then you need to understand what is involved.  By that I mean you
should start with an existing tool and learn how to write HDL without
modifying the tool.  Only then will you have an idea of how to start
porting code from a programming language to an HDL.  Then perhaps you
can figure out ways to improved the tools.

As to which tool, I can't say anything about the open source C based
tools.  I understand there is a fairly good Verilog tool called
Icarus.  That might be a good place to start.

Rick

Article: 137124
Subject: Re: which HLL for HPC applications implementation?
From: rickman <gnuarm@gmail.com>
Date: Tue, 23 Dec 2008 21:10:37 -0800 (PST)
Links: << >>  << T >>  << A >>
> what about xilinx Chimps?

BTW, I don't think Xilinx makes Chimps...  ;^)

Rick




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search