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 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. TimArticle: 155851
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? -- RickArticle: 155852
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. DavidArticle: 155853
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. DavidArticle: 155854
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
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. -- RickArticle: 155856
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
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
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. -- GaborArticle: 155859
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. -- RickArticle: 155860
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: 155861On 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
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: 155863On 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. -- johnArticle: 155864
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 TeamArticle: 155865
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, JurgenArticle: 155866
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, MarkArticle: 155867
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? -- GaborArticle: 155868
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.comArticle: 155869
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, JurgenArticle: 155870
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
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.comArticle: 155872
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
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
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:
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