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 155850

Article: 155850
Subject: Re: Lattice diamond / MachXO2
From: Tim <tim@bugblatbugblat.com>
Date: Tue, 01 Oct 2013 01:35:45 +0100
Links: << >>  << T >>  << A >>
On 29/09/2013 06:24, Joseph H Allen wrote:
> I've recently discovered that Lattice MachXO2 is quite a nice family of
> low-end FPGAs.

MachXO2 fans may be interested in this stuff:

The pif board is an XO2 FPGA that plugs onto a Raspberry Pi.
http://www.bugblat.com/products/pif

The tif board is an XO2 FPGA on a HID USB connection. HID is used so 
there is no need for software drivers.
http://www.bugblat.com/products/tif

Both boards include all the software you need to download Lattice 
Diamond JEDEC to the board, plus example designs and an example of web 
control of a design inside the FPGA.

Tim


Article: 155851
Subject: Re: Lattice diamond / MachXO2
From: rickman <gnuarm@gmail.com>
Date: Tue, 01 Oct 2013 03:31:25 -0400
Links: << >>  << T >>  << A >>
On 9/30/2013 8:35 PM, Tim wrote:
> On 29/09/2013 06:24, Joseph H Allen wrote:
>> I've recently discovered that Lattice MachXO2 is quite a nice family of
>> low-end FPGAs.
>
> MachXO2 fans may be interested in this stuff:
>
> The pif board is an XO2 FPGA that plugs onto a Raspberry Pi.
> http://www.bugblat.com/products/pif
>
> The tif board is an XO2 FPGA on a HID USB connection. HID is used so
> there is no need for software drivers.
> http://www.bugblat.com/products/tif
>
> Both boards include all the software you need to download Lattice
> Diamond JEDEC to the board, plus example designs and an example of web
> control of a design inside the FPGA.

So when does the XO3 version come out?

-- 

Rick

Article: 155852
Subject: Re: Video Framebuffer using Nexys2 (Spartan-3E)
From: David <david.manuel.dasilva@gmail.com>
Date: Tue, 1 Oct 2013 13:03:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Joel,

I have very similar project and I am thinking using a dev kit like Digilent Nexys 2 for a TFT test purpose, and I have some question. Did you solve your problem with RAM buffer, did you succeed to store the whole picture inside the PSDRAM ?

I need to test a GVIF or LVDS signals that have 50 MHz pixel clock and 24 bits RGB with Hsync and Vsync, firstly I wa thinking to store a whole image inside PSDRAM but it's looks like too slow for this purpose...

Thanks for your support.

David

Article: 155853
Subject: Re: Video Framebuffer using Nexys2 (Spartan-3E)
From: david.manuel.dasilva@gmail.com
Date: Tue, 1 Oct 2013 13:05:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Joel, 

I have very similar project and I am thinking using a dev kit like Digilent Nexys 2 for a TFT test purpose, and I have some question. Did you solve your problem with RAM buffer, did you succeed to store the whole picture inside the PSDRAM ? 

I need to test a GVIF or LVDS signals that have 50 MHz pixel clock and 24 parallel bits RGB with Hsync and Vsync (TFT have 1024 x 768 pixels), firstly I was thinking to store a whole image inside PSDRAM but it's looks like too slow for this purpose... 

Thanks for your support. 

David 

Article: 155854
Subject: Re: Lattice diamond / MachXO2
From: Tim <tim@bugblatbugblat.com>
Date: Tue, 01 Oct 2013 23:53:31 +0100
Links: << >>  << T >>  << A >>
On 01/10/2013 08:31, rickman wrote:
> On 9/30/2013 8:35 PM, Tim wrote:
>
> So when does the XO3 version come out?
>

As far as I can tell the XO3 will slot in above the XO2 and include 
stuff such as SERDES. Eventually something will replace the XO2 (only a 
couple of years old) but the XO3 parts that are being hinted at are not 
the ones.

I could very easily be completely wrong.


Article: 155855
Subject: Re: Lattice diamond / MachXO2
From: rickman <gnuarm@gmail.com>
Date: Wed, 02 Oct 2013 02:45:45 -0400
Links: << >>  << T >>  << A >>
On 10/1/2013 6:53 PM, Tim wrote:
> On 01/10/2013 08:31, rickman wrote:
>> On 9/30/2013 8:35 PM, Tim wrote:
>>
>> So when does the XO3 version come out?
>>
>
> As far as I can tell the XO3 will slot in above the XO2 and include
> stuff such as SERDES. Eventually something will replace the XO2 (only a
> couple of years old) but the XO3 parts that are being hinted at are not
> the ones.
>
> I could very easily be completely wrong.

I dunno.  A few weeks ago I sent an email asking about the new line in 
the Flash series and I was asked how I knew it existed... I guess they 
are trying to keep a tight lid on it.  Now they have some info they will 
share, but I guess you need approval from someone.  I sent in a request 
and haven't heard anything back yet.

-- 

Rick

Article: 155856
Subject: Re: VHDL syntheses timestamp
From: edmoore <edmoore1966@googlemail.com>
Date: Thu, 3 Oct 2013 02:04:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
Disadvantages with generating the timestamp from the HDL are that you might want to make changes after synthesis, for example changes to the timing constraints or initialising block rams. 

When programming the fpga in slave mode with a cpu, some people read the timestamp embedded in the .bit file, and that works well.

Article: 155857
Subject: Lattice Diamond & tristate
From: Aleksandar Kuktin <akuktin@gmail.com>
Date: Fri, 4 Oct 2013 00:38:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hello folks!

Unrelated to the other recent thread about Diamond and MachXO2, does 
anyone know how to make Lattice's Diamond and MachXO2 synthesizeand use 
tristate buffers?

Now, I'm not interested in tristates because "tristates" but because I am 
trying to save up a bit of space by using a bidirectional bus instead of 
two unidirectional. But for that, I need to alternate writing to the bus 
and that is what I need tristates for.

Pursuant of this, in my verilog sources, I have declared the relevant 
ports as bidirectional (inout), used proper constructs for alternating 
reading and writing (high impedance and all that), but when I try to 
synthesize the resulting code, Lattice's synthesizer claims an error to 
the effect "wire such_and_such is constantly being driven from multiple 
places" and stops. When I try with Synplify Pro, Synplify does synthesize 
the tristates, but when Diamond translates that to its own format, I get 
warnings similar to "unknown attribute: origin_instead_of -- 
ignoring" (I'm typing this from memory). I take that error to mean that 
the translation program removed the tristates and left me with broken 
code.

Article: 155858
Subject: Re: Lattice Diamond & tristate
From: GaborSzakacs <gabor@alacron.com>
Date: Fri, 04 Oct 2013 10:17:16 -0400
Links: << >>  << T >>  << A >>
Aleksandar Kuktin wrote:
> Hello folks!
> 
> Unrelated to the other recent thread about Diamond and MachXO2, does 
> anyone know how to make Lattice's Diamond and MachXO2 synthesizeand use 
> tristate buffers?
> 
> Now, I'm not interested in tristates because "tristates" but because I am 
> trying to save up a bit of space by using a bidirectional bus instead of 
> two unidirectional. But for that, I need to alternate writing to the bus 
> and that is what I need tristates for.
> 
> Pursuant of this, in my verilog sources, I have declared the relevant 
> ports as bidirectional (inout), used proper constructs for alternating 
> reading and writing (high impedance and all that), but when I try to 
> synthesize the resulting code, Lattice's synthesizer claims an error to 
> the effect "wire such_and_such is constantly being driven from multiple 
> places" and stops. When I try with Synplify Pro, Synplify does synthesize 
> the tristates, but when Diamond translates that to its own format, I get 
> warnings similar to "unknown attribute: origin_instead_of -- 
> ignoring" (I'm typing this from memory). I take that error to mean that 
> the translation program removed the tristates and left me with broken 
> code.

It's been a while since I last used Lattice parts, but I don't remember
them as having internal tristates.  The last Xilinx devices with
internal tristates were the Virtex (original and E) and Spartan 2
series, bith very long in the tooth, and older than the Lattice EC
and ECP devices that I first used.  So if the synthesis tool is
translating your tristates into logic, whether or not this breaks
the code, you're not likely to free up any space this way.

-- 
Gabor

Article: 155859
Subject: Re: Lattice Diamond & tristate
From: rickman <gnuarm@gmail.com>
Date: Fri, 04 Oct 2013 10:39:17 -0400
Links: << >>  << T >>  << A >>
On 10/3/2013 8:38 PM, Aleksandar Kuktin wrote:
> Hello folks!
>
> Unrelated to the other recent thread about Diamond and MachXO2, does
> anyone know how to make Lattice's Diamond and MachXO2 synthesizeand use
> tristate buffers?
>
> Now, I'm not interested in tristates because "tristates" but because I am
> trying to save up a bit of space by using a bidirectional bus instead of
> two unidirectional. But for that, I need to alternate writing to the bus
> and that is what I need tristates for.
>
> Pursuant of this, in my verilog sources, I have declared the relevant
> ports as bidirectional (inout), used proper constructs for alternating
> reading and writing (high impedance and all that), but when I try to
> synthesize the resulting code, Lattice's synthesizer claims an error to
> the effect "wire such_and_such is constantly being driven from multiple
> places" and stops. When I try with Synplify Pro, Synplify does synthesize
> the tristates, but when Diamond translates that to its own format, I get
> warnings similar to "unknown attribute: origin_instead_of --
> ignoring" (I'm typing this from memory). I take that error to mean that
> the translation program removed the tristates and left me with broken
> code.

There are *no* internal tristate buffers in today's FPGAs.  You can use 
tristate buffers on I/O pins, but that is it.  If you try to infer 
tristate buffers it will either give errors or replace the tristates 
with muxes and multiple busses.

-- 

Rick

Article: 155860
Subject: Re: Lattice Diamond & tristate
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Fri, 4 Oct 2013 15:22:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <l2l2lr$3ji$1@speranza.aioe.org>,
Aleksandar Kuktin  <akuktin@gmail.com> wrote:
>Hello folks!

>Unrelated to the other recent thread about Diamond and MachXO2, does 
>anyone know how to make Lattice's Diamond and MachXO2 synthesizeand use 
>tristate buffers?

As others have said there are no tri-states.  The next best alternative is
an OR-tree:

wor [3:0] foo;

wire [3:0] a;
wire drive_a;
assign foo = drive_a ? a : 4'd0;

wire [3:0] b;
wire drive_b;
assign foo = drive_b ? b : 4'd0;

wire [3:0] c;
wire drive_c;
assign foo = drive_c ? c : 4'd0;

etc.  It's pretty efficient since you can make a 4 input OR gate with a
single LUT, or a 16 input OR gate with two levels of LUTs.

If you try to instantiate an internal tri-state bus, the tools usually
convert it to the above (but I've not tried this in Lattice- for sure this is
what happens in Xilinx and Altera).

You should get the same generated gates with this case statement:

wire [3:0] foo;

  casex (enables) // synthesis parallel_case full_case
    4'bxxx1: foo = a;
    4'bxx1x: foo = b;
    4'bx1xx: foo = c;
    4'b1xxx: foo = d;
  endcase

This code is safer (can not result in synthesis/simulation mismatch), but
above code is usually faster unfortunately, even though the synthesis tool
should be able to infer the parallel_case:

  case (enables)
    4'b0001: foo = a;
    4'b0010: foo = b;
    4'b0100: foo = c;
    4'b1000: foo = d;
    default: foo = 4'bxxxx;
  endcase

-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 155861
Subject: Re: Lattice Diamond & tristate
From: Aleksandar Kuktin <akuktin@gmail.com>
Date: Fri, 4 Oct 2013 22:41:50 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Fri, 04 Oct 2013 15:22:46 +0000, Joseph H Allen wrote:

> In article <l2l2lr$3ji$1@speranza.aioe.org>,
> Aleksandar Kuktin  <akuktin@gmail.com> wrote:
>>Hello folks!
> 
>>Unrelated to the other recent thread about Diamond and MachXO2, does
>>anyone know how to make Lattice's Diamond and MachXO2 synthesizeand use
>>tristate buffers?
> 
> As others have said there are no tri-states.

Well f--k. Pardon the language. This significantly reduces the amount of 
fun one can have with FPGAs (internally)...

>  The next best alternative
> is an OR-tree:
> 
> wor [3:0] foo;
> 
> wire [3:0] a;
> wire drive_a;
> assign foo = drive_a ? a : 4'd0;
> 
> wire [3:0] b;
> wire drive_b;
> assign foo = drive_b ? b : 4'd0;
> 
> wire [3:0] c;
> wire drive_c;
> assign foo = drive_c ? c : 4'd0;

Hmm... I'm pretty sure this won't work. The synthesizer will again 
complain that the wire is driven from multiple sources. But I'll give it 
a try.

The thought of using OR gates has crossed my mind before, but I didn't 
really think much about it. I thought about trying something with a 
register being alternatively filled from different sources, but that also 
whouldn't do what I want it to.

Article: 155862
Subject: Re: Lattice Diamond & tristate
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Sat, 5 Oct 2013 04:23:27 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <l2ng7e$g35$1@speranza.aioe.org>,
Aleksandar Kuktin  <akuktin@gmail.com> wrote:
>On Fri, 04 Oct 2013 15:22:46 +0000, Joseph H Allen wrote:

>> In article <l2l2lr$3ji$1@speranza.aioe.org>,
>> Aleksandar Kuktin  <akuktin@gmail.com> wrote:
>>>Hello folks!

>>>Unrelated to the other recent thread about Diamond and MachXO2, does
>>>anyone know how to make Lattice's Diamond and MachXO2 synthesizeand use
>>>tristate buffers?

>> As others have said there are no tri-states.

>Well f--k. Pardon the language. This significantly reduces the amount of 
>fun one can have with FPGAs (internally)...

>Hmm... I'm pretty sure this won't work. The synthesizer will again 
>complain that the wire is driven from multiple sources. But I'll give it 
>a try.

I just tried it in LSE- it works fine.  Also it tri-state works.  Make sure
you are assigning like this:

assign bus = enable ? signal : 4'bzzzz;

It also works to have module outputs connected directly to a wor or
tri-state bus.  Annoyingly, this does not work in Altera Quartus-II.

>The thought of using OR gates has crossed my mind before, but I didn't 
>really think much about it. I thought about trying something with a 
>register being alternatively filled from different sources, but that also 
>whouldn't do what I want it to.

Ah, this is a different issue.  A 'reg' can only be driven by a single
always block (and always blocks can only directly assign to regs, not 
wires).

You can do it in simulation, but it's too difficult to untangle the dataflow
in the general case for synthesis.

You will find that you will sometimes want two always blocks to affect the
same reg in the same cycle, but the only way to do it is take a Mealy output
from one always block and use it as an input to another.  This is certainly
one cause of tendonits in for Verilog RTL coders.  To get Mealy outputs you
have to use two always blocks, one clocked and one non-clocked.  Here is the
style:

// Clocked block: you must use non-blocking assign for simulation to work
// properly.

reg [3:0] my_counter, nxt_my_counter;  // Register and input to register

always @(posedge clk or negedge reset_l)
  if (!reset_l)
    begin
      my_counter <= 0;
    end
  else
    begin
      my_counter <= nxt_my_counter;
    end

// Logic block: can use blocking or non-blocking assign, it doesn't matter.

always @(*)
  begin
    nxt_my_counter = my_counter; // Preserve logic by default

    if (increment)
      nxt_my_counter = nxt_my_counter + 1'd1;

    if (decrement)
      nxt_my_counter = nxt_my_coutner - 1'd1;
  end

// Second always block, can use Mealy outputs (nxt_xxxxx signals) as inputs.

reg [3:0] foo;

always @(posedge clk or negedge reset_l)
  if (!reset_l)
    begin
      foo <= 0;
    end
  else
    begin
      if (bar || nxt_my_counter[3])
        foo <= foo + 1'd1;
    end

-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 155863
Subject: Re: Video Framebuffer using Nexys2 (Spartan-3E)
From: John Miles <jmiles@gmail.com>
Date: Sat, 5 Oct 2013 17:38:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, March 13, 2011 11:11:18 PM UTC-7, Ste wrote:
> ...
> Since I know nothing about VHDL (I'm a Verilog boy), should I even attemp=
t
> learning VHDL to analyze the above sample code or should I just jump
> straight into writing it in Verilog from scratch?

One underappreciated tool is VHD2VL, which translates VHDL to Verilog with =
passable fidelity.  I'm not a VHDL guy either, so I use it whenever I need =
to deal with a board support package or other existing HDL modules that are=
 only available in VHDL.  It usually gets you 99% of the way to a usable Ve=
rilog implementation. =20

Its latest incarnation seems to be at http://doolittle.icarus.com/~larry/vh=
d2vl/ but he doesn't provide a Windows executable.  I posted one at http://=
www.ke5fx.com/VHD2VL_Windows_x64.zip if anyone wants to grab it.

> If I were to create a
> VHDL controller based on the links above, can I even instantize a VHDL
> module from my Verilog top module? =20

Yes, you can mix and match HDLs freely.  ISE will do the right thing automa=
tically if you add .vhd files to a Verilog project.

-- john

Article: 155864
Subject: VTR 7.0 Release Announcement
From: jasonkailuu@gmail.com
Date: Sun, 6 Oct 2013 12:48:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
To the FPGA Research Community,


We are pleased to announce the release of VTR 7.0.  VTR is an open source f=
ramework for FPGA CAD and architecture exploration.  The framework includes=
 CAD tools that map Verilog/BLIF circuits to a user defined FPGA, benchmark=
s from a variety of applications/sources, sample FPGA architecture descript=
ion files, and scripts that tie these different components together.


What is new in VTR 7.0:

- Basic carry chain support through the whole CAD flow from elaboration dow=
n to routing.

- Power analysis

- Multi-clock timing analysis with support for simple SDC timing constraint=
s

- Architecture files that describe realistic, complex FPGAs with a reasonab=
le capture of area, delay, and power values

- Post-routed netlist support for timing-driven simulation

- Increased Verilog language support (eg. memory inferencing, support for p=
arameters)

- Verilog simulation and visualization for debugging

- Faster CAD algorithms

- Better quality of results for complex FPGA logic blocks

- Graphics for Windows

- Bug fixes and user friendliness improvements (Thank you to all users who =
provided us feedback on our first release of VTR)
=20

The release may be downloaded here: http://www.eecg.utoronto.ca/vtr/terms.h=
tml

The VTR wiki and software trunk may be found here: http://code.google.com/p=
/vtr-verilog-to-routing/

We hope that VTR will continue to aid your future research on FPGA architec=
ture and CAD.


From,

The VTR Development Team

Article: 155865
Subject: Granularity of components for FPGA synthesis?
From: chthon <jurgen.defurne@gmail.com>
Date: Tue, 8 Oct 2013 10:18:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello,

I am busy designing a small microprocessor system, which I have partitioned into the data path, the micro-controller, the memory, a multiplexer for the data bus input and a couple of simple 8-bit IO ports.

I am now currently busy experimenting a little bit with layout constraints (pblocks), and I was wondering how one normally goes about deciding on which level to stop.

E.g. I have now the data path, which consists of the program counter, a couple of output registers,  register file, followed by pipeline registers, followed by the ALU, which feeds back into the register file.

Is it worth while to structure this further, taking the layout of the FPGA into account, and define these data path components so that they can be placed as separate pblocks next to each other?

Regards,

Jurgen

Article: 155866
Subject: Re: Granularity of components for FPGA synthesis?
From: gtwrek@sonic.net (Mark Curry)
Date: Tue, 8 Oct 2013 19:17:28 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <b7e47d0a-dc4f-4333-9e43-a3b6b74e8a0c@googlegroups.com>,
chthon  <jurgen.defurne@gmail.com> wrote:
>Hello,
>
>I am busy designing a small microprocessor system, which I have partitioned 
>into the data path, the micro-controller, the memory, a multiplexer for the
>data bus input and a couple of simple 8-bit IO ports.
>
>I am now currently busy experimenting a little bit with layout constraints
>(pblocks), and I was wondering how one normally goes about deciding on which
>level to stop.
>

Since you're talking about pblocks, I'm going to assume Xilinx family.
In my experience, and usually advocated by Xilinx - you're much better
off with a lighter touch - if any.  I never floorplan until forced to.
Follow good synchronous design principles.  Register often.  Apply, and
check timing contraints.  Let the tool do the rest.

On (very) rare occasions this isn't sufficient, then floorplan lightly - 
locking down RAMs/PLLs/BUFGs.

The tools just do a better down when left unconstrained.

Regards,

Mark



Article: 155867
Subject: Re: Granularity of components for FPGA synthesis?
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 08 Oct 2013 16:43:14 -0400
Links: << >>  << T >>  << A >>
Mark Curry wrote:
> In article <b7e47d0a-dc4f-4333-9e43-a3b6b74e8a0c@googlegroups.com>,
> chthon  <jurgen.defurne@gmail.com> wrote:
>> Hello,
>>
>> I am busy designing a small microprocessor system, which I have partitioned 
>> into the data path, the micro-controller, the memory, a multiplexer for the
>> data bus input and a couple of simple 8-bit IO ports.
>>
>> I am now currently busy experimenting a little bit with layout constraints
>> (pblocks), and I was wondering how one normally goes about deciding on which
>> level to stop.
>>
> 
> Since you're talking about pblocks, I'm going to assume Xilinx family.
> In my experience, and usually advocated by Xilinx - you're much better
> off with a lighter touch - if any.  I never floorplan until forced to.
> Follow good synchronous design principles.  Register often.  Apply, and
> check timing contraints.  Let the tool do the rest.
> 
> On (very) rare occasions this isn't sufficient, then floorplan lightly - 
> locking down RAMs/PLLs/BUFGs.
> 
> The tools just do a better down when left unconstrained.
> 
> Regards,
> 
> Mark
> 
> 

I'll second that.  I had the opportunity to try out PlanAhead when it
was still HierDesign, before Xilinx bought them.  I worked on a tight
V2 design for some time, then eventually found that the tools did a
better job unconstrained.  I did need to use multi-pass place&route
on that design (now part of SmartXplorer).  But I could never get
the design to place & route after constraining it to pblocks.  It
may be that a less full FPGA would have worked better with pblocks,
but these are precisely the ones that work well without any manual
placement help.

One real problem is that Map will flatten the design in order to
do global optimization.  Keeping hierarchy to facilitate the use
of pblocks actually hampers QoR during mapping.

Also you talk about "data path" which has a tendency to mean a section
of the code that goes all over the physical design.  Constraining this
to a pblock doesn't sound helpful unless you can break the data path
up into regions logically.

Now it may end up that your design has a more regular structure than
my typical designs.  In that case you might be able to win from using
manual floorplanning.  On the other hand, unless you're really trying
to optimize something for re-use in a larger design, if the tools do
a good enough job without floorplanning, why bother?

-- 
Gabor

Article: 155868
Subject: Re: Granularity of components for FPGA synthesis?
From: muzaffer.kal@gmail.com
Date: Tue, 8 Oct 2013 17:12:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, October 8, 2013 12:17:28 PM UTC-7, Mark Curry wrote:
> In article <b7e47d0a-dc4f-4333-9e43-a3b6b74e8a0c@googlegroups.com>,
> chthon  <jurgen.defurne@gmail.com> wrote:
> >Hello,
> >
> >I am now currently busy experimenting a little bit with layout constrain=
ts
> >(pblocks), and I was wondering how one normally goes about deciding on w=
hich
> >level to stop.
 Since you're talking about pblocks, I'm going to assume Xilinx family.
> In my experience, and usually advocated by Xilinx - you're much better
> off with a lighter touch - if any.  I never floorplan until forced to.
> Follow good synchronous design principles.  Register often.  Apply, and
> check timing contraints [sic].  Let the tool do the rest.

My suggestions would also be let the tool do it first and see it makes the =
timing you need (if you have a spec). If you are looking to go as fast as p=
ossible, it might make sense to open the layout and start clicking on the s=
lowest paths and see how the components are placed. Sometimes one sees quit=
e suboptimal choices by the placer and it helps to write some placement con=
straints based on that.=20

Of course this is only the second step. First one has to look at the genera=
ted blocks and see if the synthesizer is making any sub-optimal choices. Th=
is usually happens with selection of existing hardmacros vs fabric elements=
. As an example it turns out the next version of the Vivado synthesizer lik=
es inferring DSP48s quite a bit and would use one even though the same logi=
c with fabric elements would be much faster, forcing one to sprinkle "use_d=
sp48 =3D no" constraints all over the RTL. Annoying but necessary.

kal@dspia.com

Article: 155869
Subject: Re: Granularity of components for FPGA synthesis?
From: chthon <jurgen.defurne@gmail.com>
Date: Tue, 8 Oct 2013 22:48:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
Thanks for the answers. I will keep what I have now of floorplanning, becau=
se I like to have a clean result (ISE seems to throw stuff around like an e=
xpanding gas cloud), but I will keep it at that. I now get 190 MHz, I do no=
t have a spec, but I wanted to know how fast I (clockwise) I could make my =
design. And it is now mostly hampered through the fact that I use 64k bytes=
 of block RAM, which I really had to constrain, because without this it use=
s block RAM in weird places.

Regards,

Jurgen

Article: 155870
Subject: Book recommendation
From: Paulo Ricardo Pabst <prpabst@gmail.com>
Date: Wed, 9 Oct 2013 10:02:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I'm new on this group. I'm starting my final year's project and I'm building a "interpolated multi-axis controller" (aka NC controller).

I will use a FPGA (probably an spartan 3) to build a DDS, a quadrature encoder interface and some others digital circuits.

My knowledge about VHDL is not really good, I'd read some tutorials about VHDL and I played with VHDL a little. But what I don't know is the best way to implement these digital circuits.

So, what I want is some suggestions about what book I need to buy to learn how implement configuration registers, QEI, DDS, microcontroller interface, etc. I see some books on amazon, but I'm still in doubt about them.

TIA,
Paulo Ricardo.

Article: 155871
Subject: Re: Book recommendation
From: Tim Wescott <tim@seemywebsite.really>
Date: Wed, 09 Oct 2013 12:48:08 -0500
Links: << >>  << T >>  << A >>
On Wed, 09 Oct 2013 10:02:43 -0700, Paulo Ricardo Pabst wrote:

> Hi,
> 
> I'm new on this group. I'm starting my final year's project and I'm
> building a "interpolated multi-axis controller" (aka NC controller).
> 
> I will use a FPGA (probably an spartan 3) to build a DDS, a quadrature
> encoder interface and some others digital circuits.
> 
> My knowledge about VHDL is not really good, I'd read some tutorials
> about VHDL and I played with VHDL a little. But what I don't know is the
> best way to implement these digital circuits.
> 
> So, what I want is some suggestions about what book I need to buy to
> learn how implement configuration registers, QEI, DDS, microcontroller
> interface, etc. I see some books on amazon, but I'm still in doubt about
> them.

How much do you know about digital design already?  A good VHDL book 
isn't going to tell you much about digital design -- it's going to tell 
you how, after you know what you want, you can translate that desire into 
VHDL.  So if your first problem is that you have no clue what a DDS, a 
quadrature encoder interface, and those other digital circuits should do, 
then your primary need is not a VHDL book.

If that's the case, then you want to look for a book with a title that's 
more along the line of "Digital Logic Design (with VHDL)"; i.e., you want 
a book about digital logic design that uses VHDL to convey the design 
content.  This will fill in your most crying need, and hopefully give you 
enough VHDL chops to get you by.

The book on my shelf is the opposite.  It's "The Designer's Guide to VHDL" 
by Peter Ashenden, and its meant for people who know digital design, but 
not VHDL.  

Keep in mind, though, that I'm no VHDL expert, and the book was just the 
likeliest-looking one at Powell's when I went shopping.  I'd look to it 
only if no one else coughs up a title.  It proved adequate to what I was 
doing, but what I was doing was largely showing that an algorithm was 
feasible _at all_; once I had a first cut working the real FPGA designers 
on the project took it out of my hands and made it work with fewer gates 
and at a higher clock rate and all that good stuff.

Unless your prof is demanding that you do this with an FPGA, or unless 
you want to use an FPGA just because, you may want to consider 
implementing those functions on the microcontroller that you're 
interfacing with.  I'm certainly not saying you definitely _should_ -- 
I've just found that it's often cheaper to pull moderate-speed "logic" 
functions into the micro, particularly if I'm at liberty to shop for the 
microprocessor I need (for instance: many micros these days are made 
specifically for motor control, and have quadrature encoder interfaces 
built in).

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com


Article: 155872
Subject: Re: Book recommendation
From: Paulo Ricardo Pabst <prpabst@gmail.com>
Date: Wed, 9 Oct 2013 13:07:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
Em quarta-feira, 9 de outubro de 2013 10h48min08s UTC-7, Tim Wescott  escre=
veu:
> On Wed, 09 Oct 2013 10:02:43 -0700, Paulo Ricardo Pabst wrote:
>=20
>=20
>=20
> > Hi,
>=20
> >=20
>=20
> > I'm new on this group. I'm starting my final year's project and I'm
>=20
> > building a "interpolated multi-axis controller" (aka NC controller).
>=20
> >=20
>=20
> > I will use a FPGA (probably an spartan 3) to build a DDS, a quadrature
>=20
> > encoder interface and some others digital circuits.
>=20
> >=20
>=20
> > My knowledge about VHDL is not really good, I'd read some tutorials
>=20
> > about VHDL and I played with VHDL a little. But what I don't know is th=
e
>=20
> > best way to implement these digital circuits.
>=20
> >=20
>=20
> > So, what I want is some suggestions about what book I need to buy to
>=20
> > learn how implement configuration registers, QEI, DDS, microcontroller
>=20
> > interface, etc. I see some books on amazon, but I'm still in doubt abou=
t
>=20
> > them.
>=20
>=20
>=20
> How much do you know about digital design already?  A good VHDL book=20
>=20
> isn't going to tell you much about digital design -- it's going to tell=
=20
>=20
> you how, after you know what you want, you can translate that desire into=
=20
>=20
> VHDL.  So if your first problem is that you have no clue what a DDS, a=20
>=20
> quadrature encoder interface, and those other digital circuits should do,=
=20
>=20
> then your primary need is not a VHDL book.
>=20
>=20
>=20
> If that's the case, then you want to look for a book with a title that's=
=20
>=20
> more along the line of "Digital Logic Design (with VHDL)"; i.e., you want=
=20
>=20
> a book about digital logic design that uses VHDL to convey the design=20
>=20
> content.  This will fill in your most crying need, and hopefully give you=
=20
>=20
> enough VHDL chops to get you by.
>=20
>=20
>=20
> The book on my shelf is the opposite.  It's "The Designer's Guide to VHDL=
"=20
>=20
> by Peter Ashenden, and its meant for people who know digital design, but=
=20
>=20
> not VHDL. =20
>=20
>=20
>=20
> Keep in mind, though, that I'm no VHDL expert, and the book was just the=
=20
>=20
> likeliest-looking one at Powell's when I went shopping.  I'd look to it=
=20
>=20
> only if no one else coughs up a title.  It proved adequate to what I was=
=20
>=20
> doing, but what I was doing was largely showing that an algorithm was=20
>=20
> feasible _at all_; once I had a first cut working the real FPGA designers=
=20
>=20
> on the project took it out of my hands and made it work with fewer gates=
=20
>=20
> and at a higher clock rate and all that good stuff.
>=20
>=20
>=20
> Unless your prof is demanding that you do this with an FPGA, or unless=20
>=20
> you want to use an FPGA just because, you may want to consider=20
>=20
> implementing those functions on the microcontroller that you're=20
>=20
> interfacing with.  I'm certainly not saying you definitely _should_ --=20
>=20
> I've just found that it's often cheaper to pull moderate-speed "logic"=20
>=20
> functions into the micro, particularly if I'm at liberty to shop for the=
=20
>=20
> microprocessor I need (for instance: many micros these days are made=20
>=20
> specifically for motor control, and have quadrature encoder interfaces=20
>=20
> built in).
>=20
>=20
>=20
> --=20
>=20
>=20
>=20
> Tim Wescott
>=20
> Wescott Design Services
>=20
> http://www.wescottdesign.com

Tim,

Thanks for quick answer. I've 12 years of experience in electronics design.=
 So I able to do digital design and I know a little of VHDL. What I need is=
 a book that teaches me the best way to make the project. I need to learn h=
ow to "...make it work with fewer gates and at a higher clock rate and all =
that good stuff."

Paulo.

Article: 155873
Subject: Re: Book recommendation
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Wed, 09 Oct 2013 21:24:46 +0100
Links: << >>  << T >>  << A >>
On 09/10/13 21:07, Paulo Ricardo Pabst wrote:
> Thanks for quick answer. I've 12 years of experience
 > in electronics design. So I able to do digital design
 > and I know a little of VHDL. What I need is a book that
 > teaches me the best way to make the project. I need to
 > learn how to "...make it work with fewer gates and at
 > a higher clock rate and all that good stuff."

Since I haven't used VHDL before, I /am/ interested in
pointers to VHDL "style guides", by which I mean:
   - coding patterns and anti-patterns
   - clean directory tree structures for libraries and packages
   - anything else that helps me avoid messy pitfalls
I have seen a few such style guides around, but none
of them are really satisfying!

I have more years electronic experience than I care to
recall, so I'll figure out ways to condense logic and
speed up logic (in my experience each device manufacturer
tends to produce good info about their devices).

Article: 155874
Subject: Re: Book recommendation
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 10 Oct 2013 03:05:18 +0000 (UTC)
Links: << >>  << T >>  << A >>
Paulo Ricardo Pabst <prpabst@gmail.com> wrote:

(snip)
> Thanks for quick answer. I've 12 years of experience in 
> electronics design. So I able to do digital design and I know 
> a little of VHDL. What I need is a book that teaches me the 
> best way to make the project. I need to learn how to "...make 
> it work with fewer gates and at a higher clock rate and all 
> that good stuff."

For FPGAs logic optimization is a little different from the 
TTL days. For one, any four intput (or, now, 6 input) one output
logic block can be implemented in an LUT. More important for 
speed and high clock rates is pipelining, also because FPGAs
have FFs on each LUT output. (At least many do.) 

There used to be books on the architecture of pipelined computers,
from the days of the IBM 360/91 and Cray-1. Some of the ideas
still work, and some don't. 

The optimizations that the synthesis tools do make it hard to know
which things you need to know and which you don't.

I don't know of any books on optimization for FPGAs, but that
doesn't mean that there aren't any.

-- glen



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