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 Feb 9, 1:55 am, DJ Delorie <d...@delorie.com> wrote:
> Not much compared to the "norm" around here, but...
>
> http://www.delorie.com/electronics/bin2seven/
I remember seeing the thread in s.e.d. :)
To enhance readability a bit, I would keep the BCD value as a 10 bit
vector, rather than split it up between the 3 digits.
In bcd.v, you can then write your case statement as:
case (ibin)
0 : bcd = 10'h0;
1 : bcd = 10'h1;
2 : bcd = 10'h2;
3 : bcd = 10'h3;
...
255 : bcd = 10'h255;
endcase
In top.v, extract the individual digits for further processing:
wire [1:0] bcd2 = bcd[9:8];
wire [3:0] bcd1 = bcd[7:4];
wire [3:0] bcd0 = bcd[3:0];
Article: 128901Hi I have a few (5 at the moment) of NDS CPLD boards manufactured, the preliminary user manual is here http://code.google.com/p/nds-homebrew/downloads/list from that public google project are also available VHDL examples and C code for this CPLD board the C code example includes Xilinx XSVF player adapter to NDS ARM9 It fits the NDS slot-2 and can be reprogrammed in system, there are many application areas like wifi-enables JTAG programmer, etc.. NDS is a nice portable wife-enabled platform, the CPLD add on makes it useable for many applications like standalone programmer, etc. etc. as I only have 5 pieces from the manufacturing test batch they are only for sell at ebay http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=190197495055 the production site is however ready to make them at short notice Antti LukatsArticle: 128902
FPGA a écrit : > I want to do a simulation only version right now (some requirements > change on the fly :) ). The sin/cos wave has to be implemented in such > a way that it can be used as an input to ant UUT. I am not yet sure if > this would work by using a function. What other options do I have? I > cannot use it as a component. I am making a library of functions so I > want to make this as generic as possible. If i implement this using a > process, where can this go in a package? Hello You can not generate a waveform using a function only. A function computes an output value based on input values. I think a procedure is what you want. NicolasArticle: 128903
On 9 Feb., 11:05, Nicolas Matringe <nicolas.matri...@fre.fre> wrote: > > Hello > You can not generate a waveform using a function only. A function > computes an output value based on input values. > I think a procedure is what you want. The input value could be the frequency and the number of samples, the output value could be an array of real contining the waveform. Not very useful for synthesis, but a good solution for a testbench. type real_array is array(natural range<>) of real; function sinewave(f: real; n: natural) return real_array; Kolja SulimmaArticle: 128904
>Not much compared to the "norm" around here, but... >http://www.delorie.com/electronics/bin2seven/ Don't worry about the norm. Keep a clarity of exposition in your code and you'll soon overtake most other engineers (who often can't communicate their work clearly after 20-30 years). "I still think people could be documenting what they write much better" (Knuth, 1996) MikeArticle: 128905
DJ Delorie <dj@delorie.com> wrote: > >Not much compared to the "norm" around here, but... > >http://www.delorie.com/electronics/bin2seven/ I would have tried a 256 way case converting directly from 8 bit binary to 16 segments including the leading zero blanking function. Effectively expressing the ROM solution in verilog. Let the synthesiser do the work. I don't know how 'big' the result would be but you might be pleasantly surprised. Also it might be more efficient to latch the segment outputs not the binary inputs (at the expense of a little extra data hold time). The macro cells driving the segments have flip flops which are otherwise unused. I also noticed you are outputting oz for blanking, that probably takes more logic that forcing inactive for blanking. --Article: 128906
On Feb 9, 5:40=A0am, "comp.arch.fpga" <ksuli...@googlemail.com> wrote: > On 9 Feb., 11:05, Nicolas Matringe <nicolas.matri...@fre.fre> wrote: > > > > > Hello > > You can not generate a waveform using a function only. A function > > computes an output value based on input values. > > I think a procedure is what you want. > > The input value could be the frequency and the number of samples, > the output value could be an array of real contining the waveform. > > Not very useful for synthesis, but a good solution for a testbench. > > type real_array is array(natural range<>) of real; > function sinewave(f: real; n: natural) return real_array; > > Kolja Sulimma Thank you so much for your help. I appreciate it. I will try your suggestions and see how it works out.Article: 128907
On Sat, 9 Feb 2008 02:40:45 -0800 (PST), "comp.arch.fpga" <ksulimma@googlemail.com> wrote: >On 9 Feb., 11:05, Nicolas Matringe <nicolas.matri...@fre.fre> wrote: > >> >> Hello >> You can not generate a waveform using a function only. A function >> computes an output value based on input values. >> I think a procedure is what you want. > >The input value could be the frequency and the number of samples, >the output value could be an array of real contining the waveform. > >Not very useful for synthesis, but a good solution for a testbench. Actually quite useful for synthesis; the array returned can be the lookup table in a sine wave generator. (although Xilinx XST may be unbelievably slow in evaluating the function) >type real_array is array(natural range<>) of real; >function sinewave(f: real; n: natural) return real_array; - BrianArticle: 128908
"Antti" <Antti.Lukats@googlemail.com> wrote in message news:6d71426b-fffe-4284-b046-db43b4876c79@i7g2000prf.googlegroups.com... > > NDS is a nice portable wife-enabled platform, > Yeah, but is she any good at Super Mario? :-) Cheers, Syms.Article: 128909
On 9 Feb., 15:31, "Symon" <symon_bre...@hotmail.com> wrote: > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > news:6d71426b-fffe-4284-b046-db43b4876c79@i7g2000prf.googlegroups.com... > > > NDS is a nice portable wife-enabled platform, > > Yeah, but is she any good at Super Mario? > :-) > Cheers, Syms. LOL, uuups wi-fi not wife! ROTFL BTW, at school when I was asked to write "LOVE" I wrote "LAW" Antti is smilingArticle: 128910
On Feb 9, 6:22 am, John Adair <g...@enterpoint.co.uk> wrote: > Alfredo > > I'm not sure you will find a product like this. Most of the DSP > orientated boards with ADC/DAC at this level tend be lined up with > Virtex level FPGAs. > > I would also make the observation that the PQ208 package relatively > poor at handling high speed I/O compared to BGA based parts and if we > were designing a development board of this specification we certainly > would not be using the PQ208 package. > > Not quite what you want and not a pretty solution but some of the > Linear Tech ADC demo boards can plug into our Broaddown2 Spartan-3 > Development, with minor mods, on the edge connector Alternatively you > might also to be able to wire something like our Drigmorn1/Craignell > boards (fitted with either XC3S100E-4CPG132C or XC3S500E-4CPG132C) on > a high quality breadboard together with Linear Technology boards. > > Longer term we do have plans for middle end ADC/DAC modules to support > all of our products that have DIL headers on them and for the very > high end ADC/DAC there will be a Moel-Bryn module/s and another > format(to be announced) that will support the forthcoming Hollybush2 > product. > > John Adair > Enterpoint Ltd. - Home of Raggedstone1. The Low Cost Spartan-3 PCI > Development Board. > > On 8 Feb, 10:51, Alfreeeeed <Alfredo.Tad...@gmail.com> wrote: > > > Hi everybody , I am looking for a development board. My intention is > > to devolp a DSP application so ideally should contain : > > > -xc3s500e-pq208 > > -ADC <80Msps <10bit > > -DAC same specifications. > > > -The PROM and JTAG interface is not an issue . I have a JTAG > > programmer for PROMS. > > > I would reaaly appreciate your help. > > > Alfredo Taddei Yes John, you are absolutely right. There is no such a product like the one I am looking for. I give up. All the boards you suggested , were already visited.The project is meant to implement two IIR filters( with programable coeffs) in one of these spartan3 , and it doent require high-speed(25Mhz) but low-cost , and thispackage is easier to mount (according to what I heard). We will have to develop our own board.I am skilled at programming VHDL for DSP specially , so I will have to ask a PCB designer here in my company to do the wok for me. Thanks folks for the valuable information you share in this group. Best Regards, Alfredo TaddeiArticle: 128911
One could rant for hours about #1, and all sorts of similar things that may be done with the idea of supporting design reuse, maintainability, lowest-common-denominator quality, ... but I shall refrain. In regards to #2: I think it's a good idea. However, what does the statement mean? I think the case of static control signals could be covered by an explicit multi-cycle constraint or TIG. Then, the exceptions to the global clocking constraints are documented. Clock-domain crossings need to be managed in the design architecture, and most likely at the constraint level. Leaving those constraints out may result in a working design, but sometimes the tools just do the unexpected--really badly. In the distant past, I found I got better results (successful timing closure w/ a working design) by purposely NOT constraining certain paths, but instead using location constraints to put the source and destination points next to each other. Since that time, the tools & constraint defintions gave gotten much better (but manual placement still helps on critical paths.) JTW "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in message news:612s4eF1r1evbU1@mid.individual.net... > I've been working as a 'consultant' / sub contract engineer with > a strong emphasis on FPGA work for about eight years now (after > a previous eight stint as a permanent employee with a large Telco). > > I have come across a couple of odd customer style guide requirements > which are... > > 1) Only one process per clock is allowed per entity (hello Nick). > > I never understood the thinking behind this. > > I normally structure my code the way I had partitioned a design, > for example a process for low level control with a higher level > 'protocol' process in an I2C interface. > > To me this makes the code easier to read/support but this can't > be done with one process. > > > > 2) There must be no unconstarined paths in a design. > > This is madness and only causes problems with support. I was asked > to modify a (large) design which I did, only then the P&R was failing. > It was a module I hadn't worked on that had failed so I had to dig > into the workings of that module to work out what was goign on. It > turned out that a constraint of the previous results + 20% had been > added, but this was a static area of the design that didn't need > to be constrained. It lost me a day or two investigating. > > > > Anyone got any strong opinions, especially on 'one process', or come > across other oddities? > > > > Nial. >Article: 128912
Arlet <usenet+5@c-scape.nl> writes: > 255 : bcd = 10'h255; Neat trick, thanks. I use a perl script to generate the big tables anyway, so readability wasn't high on my list.Article: 128913
On 7 feb, 10:29, taco <trala...@joepie.nl> wrote: > We are want to use a spartan 3E in the very small chip scale package because > of space constraints. However the 4 MBit serial prom for this device is > almost the same size as the whole fpga. Does anybody know of an alternative > which is much smaller? > Taco Walstra > University of Amsterdam check at Xilinx web for the Spartan 3AN.Article: 128914
nospam <nospam@please.invalid> writes: > I would have tried a 256 way case converting directly from 8 bit > binary to 16 segments including the leading zero blanking > function. Effectively expressing the ROM solution in verilog. I started with that, but consider the blanking, lzblanking, and inverting - that's a 2048 way case. Plus, I wouldn't have had reusable BCD and 7segment modules left over ;-) > Let the synthesiser do the work. I don't know how 'big' the result > would be but you might be pleasantly surprised. I found that the size of the result was somewhat independent of the way I expressed the logic (I tried a LOT of ways trying to fit it into the '36). So I might as well go with something that's readable, editable, and reusable. > Also it might be more efficient to latch the segment outputs not the > binary inputs (at the expense of a little extra data hold time). The > macro cells driving the segments have flip flops which are otherwise > unused. That keeps you from using the blanking signal as a PWM brightness control, or the polarity signal to drive LCDs. > I also noticed you are outputting oz for blanking, that probably > takes more logic that forcing inactive for blanking. I figured since the output drivers had unused enables already, it would just hook into those, saving some gates.Article: 128915
On 9 Feb., 20:24, Walter <wsf...@adinet.com.uy> wrote: > On 7 feb, 10:29, taco <trala...@joepie.nl> wrote: > > > We are want to use a spartan 3E in the very small chip scale package because > > of space constraints. However the 4 MBit serial prom for this device is > > almost the same size as the whole fpga. Does anybody know of an alternative > > which is much smaller? > > Taco Walstra > > University of Amsterdam > > check at Xilinx web for the Spartan 3AN. S3-AN is not availalable in small packages :( so s3e-132+qfn flash take less space than smallest s3an AnttiArticle: 128916
> <want.a.friendlier.world@gmail.com> wrote in message > news:1a8a5571-0b38-42aa-a783-bf53ffc36cf6@m34g2000hsf.googlegroups.com... > On Feb 7, 12:08 am, "Tony Burch" <t...@burched.com.au> wrote: > > Hi all, > > I thought I would share this report that I just wrote called "Single Top > > FPGA Tips".http://www.burched.com/BurchED_Single_Top_Tips.pdf > > > > It's a bit different to your normal "Top Ten Tips" or "Favourite > > Recipes" > > because I tried to write a single tip for each level of FPGA designer, > > right > > through from "not yet started" to "experienced". > > > > I hope you enjoy it! > > Kind regards, > > Anthony Burch > > Very informative..! Thanks Tony. > > Slightly off topic, but what's going on with BurchEd? I've been > wanting to get one of your boards for some time... Thanks mate! Exciting things are happening at BurchED...several projects in the pipleine aimed at helping FPGA designers. I can't say more than but if you want to be the first to know you can subscribe to FPGA News at http://www.burched.com We no longer make the BurchED Brand boards but there are some great value boards available from many places, including Digilent http://www.digilentinc.com/ In my opinion, these Digilent ones look great: * Basys, Spartan3, $59 * Spartan 3 Starter Board $99 (some nice fast SRAM on there instead of SDRAM) * Nexys 2, Spartan 3E, $99 * Spartan 3E Starter Board, Spartan 3E, $149 (I personally have this one) For Altera, I like Terasic boards www.terasic.com * Altera DE1, Cyclone II, $150 (personally I have their earlier Terasic TREX C1 but that is no longer available) By the way, can anyone give personal recommendations for some nice Lattice or Actel boards? Kind regards, Anthony Burch http://www.BurchED.com Getting Started With Xilinx FPGAs Video GuideArticle: 128917
> After a day of fighting with UrJTAG I gave up on that Hi, we'd really like to help, maybe it's just lack of documentation, maybe there's something wrong in UrJTAG... FT2232 support is still work in progress - please report your problems at http://urjtag.org ! Or by mail to one of the authors, e.g. me. Otherwise we maybe don't even know that something's wrong. KoljaArticle: 128918
On Fri, 8 Feb 2008 11:18:34 -0000, Nial Stewart wrote:
>I have come across a couple of odd customer style guide requirements
>which are...
>
>1) Only one process per clock is allowed per entity (hello Nick).
>
>I never understood the thinking behind this.
Agreed. I normally find myself fighting against the opposite
problem - people with a very hardware-ish mindset writing one
process for each tiny little bit of functionality "to make it
easy to understand" (which, of course, it doesn't; that's like
saying you can most easily understand the schematic of a big
CPU if it's all drawn as NAND gates). But your rule is
bizarre and utterly unnecessary.
It's also plain flat-out wrong, if you have a design in
which some of the registers have asynch resets and some
don't; using the traditional form of synchronous
process, you need two different processes for the two
sets of registers (though we have discussed alternatives
here, in the past).
If this is VHDL we're talking about, processes offer a very
important packaging/data-hiding construct, the variable.
Enforcing that the whole architecture be in one process
means that you can't have individual chunks of functionality
hide their inner workings from others. Silly.
I absolutely agree that it's a smart move to keep the number
of processes reasonably small (and, of course, Mike Treseler
would be even more emphatic about that). But to suggest that
there should be only one per clock is truly nonsensical.
What rationale is given for that rule?
>I normally structure my code the way I had partitioned a design,
>for example a process for low level control with a higher level
>'protocol' process in an I2C interface.
>
>To me this makes the code easier to read/support but this can't
>be done with one process.
Absolutely agreed.
Just a thought (thanks Mike):
process (clock)
begin
if rising_edge(clock) then
low_level_control_procedure(...);
protocol_procedure(...);
end if;
end process;
Only one process, with two bodies coded in two procedures.
You might - just might - get away with that....
>2) There must be no unconstarined paths in a design.
>
>This is madness and only causes problems with support.
Does this truly mean "no unconstrained paths", or does it
mean "no path without its own explicit constraint"?
You could quite reasonably argue that a simple frequency
constraint on each clock in the design is sufficient
to constrain every path in the design. If the customer is
indeed asking for an explicit constraint on every path, then
you should point out the exceedingly large increase in your
fees that will be called for if you are to maintain the
constraints across all future changes of register size,
name and so forth. Mutter darkly about wanting to insert
a few extra pipeline stages. Pace up and down the room in
an agitated manner discussing (to yourself, of course) the
finer points of synthesis name rewriting rules. Calculate
the expected cost of rewriting all the constraints if the
customer migrates his synthesis to a different tool.
This requirement sounds to me like a mangled and misunderstood
reworking of something more sensible such as "every I/O pad
must have an appropriate setup/hold or output-delay constraint".
>Anyone got any strong opinions, especially on 'one process',
> or come across other oddities?
I suspect that oddities rather come with the territory when
you're working as a contractor. Like the design I had to
rework a few years back, which had started life as a schematic
and caused Quartus to report something like 130 different
clocks...
Good luck.
--
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: 128919
Jonathan Bromley wrote:
> It's also plain flat-out wrong, if you have a design in
> which some of the registers have asynch resets and some
> don't; using the traditional form of synchronous
> process, you need two different processes for the two
> sets of registers (though we have discussed alternatives
> here, in the past).
Hello Jonathan,
Yes, I break this guideline sometimes to infer
a blockram process, but I have yet to come across any
other reason to exclude resets for an FPGA design process.
They make simulation easier and they are free.
> If this is VHDL we're talking about, processes offer a very
> important packaging/data-hiding construct, the variable.
> Enforcing that the whole architecture be in one process
> means that you can't have individual chunks of functionality
> hide their inner workings from others. Silly.
It also forces the designer to use variables as registers,
which is why I was amazed that anyone other than I would
consider such a guideline. It is more likely that
the customer does not understand its implications.
Whether it is silly or not depends on the designer's
relationship with wires.
I prefer to let synthesis infer most of these inside the
design entity/process and keep all the explicit
signal declarations in the top structural entity for wiring ports.
An entity/process hides variables just as well as a process does.
> I absolutely agree that it's a smart move to keep the number
> of processes reasonably small (and, of course, Mike Treseler
> would be even more emphatic about that). But to suggest that
> there should be only one per clock is truly nonsensical.
> What rationale is given for that rule?
I agree that this is a matter of style.
If you don't mind declaring and hooking
up your own wires between processes -- go for it.
>...
> Only one process, with two bodies coded in two procedures.
> You might - just might - get away with that....
You certainly can for non-synopsys synthesis.
I don't know for sure that synopsys still
has a problem with procedures because I haven't
had a volunteer to synthesize my reference design
on synopsys for more that three years.
>...
> I suspect that oddities rather come with the territory when
> you're working as a contractor. Like the design I had to
> rework a few years back, which had started life as a schematic
> and caused Quartus to report something like 130 different
> clocks...
I'll bet that was redo ;)
-- Mike Treseler
Article: 128920
Mike Treseler wrote:
> It also forces the designer to use variables as registers,
Whoops. No it doesn't. Consider this statement retracted.
-- Mike Treseler
Article: 128921On Sun, 10 Feb 2008 11:53:33 -0800, Mike Treseler wrote: >Jonathan Bromley wrote: >> Only one process, with two bodies coded in two procedures. >> You might - just might - get away with that.... > >You certainly can for non-synopsys synthesis. >I don't know for sure that synopsys still >has a problem with procedures because I haven't >had a volunteer to synthesize my reference design >on synopsys for more that three years. I didn't mean "you can make it work" - I'm pretty sure DC and all the other realistic synth tools can handle procedures today, provided they make sense as the body of an RTL process. What I meant was that if the customer is so dopey as to impose a rule like that, they're also probably too dopey to notice you weaseling your way around their idiot rule by writing a bunch of procedures. This is a perfect cue for the embarrassing moment when Nial points out that his client got their style guidance from us..... nah, just kidding (I hope) :-) -- 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: 128922
Hellow,
i try to test xilinx IP core and with modelsim but it give error
regarding unisim library
# Reading D:/Modeltech_pe_edu_6.3c/tcl/vsim/pref.tcl
# do {testfft.fdo}
# ** Warning: (vlib-34) Library already exists at "work".
# Model Technology ModelSim PE Student Edition vcom 6.3c Compiler
2007.09 Sep 11 2007
# -- Loading package standard
# -- Loading package std_logic_1164
# ** Error: fftk4.vhd(37): Library unisim not found.
# ** Error: fftk4.vhd(38): (vcom-1136) Unknown identifier "unisim".
# ** Error: fftk4.vhd(39): (vcom-1136) Unknown identifier "unisim".
# ** Error: fftk4.vhd(41): VHDL Compiler exiting
# ** Error: D:/Modeltech_pe_edu_6.3c/win32pe_edu/vcom failed.
# Error in macro ./testfft.fdo line 5
# D:/Modeltech_pe_edu_6.3c/win32pe_edu/vcom failed.
# while executing
# "vcom -explicit -93 "fftk4.vhd""
what should i do?
Article: 128923kian.zarrin@gmail.com wrote: > # ** Error: fftk4.vhd(37): Library unisim not found. > # ** Error: fftk4.vhd(38): (vcom-1136) Unknown identifier "unisim". > what should i do? http://groups.google.com/groups/search?q=modelsim+unisim+libraryArticle: 128924
Nial Stewart wrote: > 1) Only one process per clock is allowed per entity (hello Nick). Craziness! This probably descibes my coding style early-on, when I didn't have much experience. But after reading many more examples (in both Verilog and VHDL) and via my own experiences I've found that using multiple processes with the same clock within the same entity - done properly - vastly improves readability, comprehension and maintenance. Of course as always there's a trade-off, and you have to decide when to use multiple processes, when to instantiate sub-entities etc etc, but an example I commonly use it to implement registers in one process, and other functionality in another. I'm actually starting to use blocks more often now, to avoid long lists of signals in the entity declaration that are hard to find in the code. If there's a functional block that I don't want to instantiate as another nested entity, I'll use a block and define any local signals that have no scope outside the function. I guess I should also mention that my original background is software, so perhaps I'm coming in with a different mind-set. Feel free to disagree, but I doubt you'll change my mind. I've seen enough code now (good and bad) to know what I do and don't like... ;) Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266
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