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 Apr 20, 5:14=A0pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> On Apr 20, 11:46=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> > > >http://sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf
>
> > > The infamous Guideline #5 bans variable semantics from always blocks
> > > with sequential logic. It must be the Worst Guideline ever for RTL
> > > designers.
> > > The result is not wizardry but ignorance.
>
> > > How are we supposed to "raise the abstraction level" if Verilog RTL
> > > designers
> > > can't even use variables?
>
> > I didn't notice this post until today. =A0I think you are completely
> > misreading the guidelines if you think they mean "Verilog RTL
> > designers can't even use variables"
>
> I use that line as a shorthand for "Guideline #5 combined with
> Guideline #1, if taken seriously, forbids the use of traditional
> variable semantics provided by blocking assignments, in the
> context of a clocked always block".
>
> No matter how absurd I hope this sounds to you, that's really
> what it says.
Well, the guidelines absolutely _do_ "forbid the use of traditional
variable semantics provided by blocking assignments, in the context of
a clocked always block", but I don't think that translates into
"Verilog RTL designers can't even use variables."
What it *does* translate into is "The cleanest way to write Verilog is
somewhat verbose, in that it requires you to separate your
combinatorial logic from your sequential logic."
Basically, this method of thinking/coding requires two variables for
each sequential variable. It's really handy to have a nice naming
convention, like next_x is the variable that will be placed into x on
the next clock.
So you have your definitions:
reg y, next_y;
reg [5:0] x, next_x;
and your combinatorial block:
always @* begin
next_x =3D x + 1;
next_y =3D x =3D=3D 0;
end
and your sequential block:
always @(posedge clk or negedge rstn)
if (!rstn) begin
x <=3D 0;
y <=3D 0;
end else begin
x <=3D next_x;
y <=3D next_y;
end
The declaration of registers and the sequential block both become,
pretty much, boilerplate code with this method of coding -- all the
action happens in the combinatorial block. I am actually, slowly, in
my spare time, working on a project that will create a lot of the
boilerplate for coding in this method.
How does this help? It's more about a human's ability to mentally
manage complexity than anything else. In the sequential block, every
line must be 'xxx' <=3D next_'xxx'. Very easy to verify. In the
combinatorial block, 'next_' must appear on the lhs, and only on the
lhs, of any assignment involving a sequential variable. Nothing keeps
you from using if, case statements, etc. in the combinatorial block,
and it's very easy to think about, because you see two variables
simultaneously -- what is 'x' right now, and what will 'x' be after
the next clock.
I have worked at several companies and with several individuals where
this coding style is used. I did not invent it; as far as I know it
was probably invented at multiple places independently. It works
quite well, but is, as I mentioned, a bit verbose. There is no reason
to use it for extremely simple modules, but OTOH, the breakover point
where it is better to use it comes much sooner than you might think.
Regards,
Pat
Article: 147251On Apr 19, 9:53=A0am, "Smith" <sm...@donotwantmail.com> wrote: > Hello all > > I need to run an old firmware for a Siemens SAB 80C537 microcontroller un= it > (MCU). The MCU is now obsolete (it's from the late 1980s). > > The firmware is compiled from several thousand rows of assembly language.= It > would take a long time to understand the code and re-program it in C. > > So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware > code without any changes to the code. > > Any one here had any luck with this kind of problem? The 8031/8051 architecture or compatible MCUs are still being used. When I was at KODAK it was used in a couple of different parts of a minilab system for controlling and synchronizing motors. I recently interviewed with a avionics company that uses it for digital displays in the cockpit of the plane (it is easy to get certfied for the FAA). Don't write it off yet... DerekArticle: 147252
The CTO of Xilinx, during his keynote this morning at the Reconfigurable Architectures Workshop in Atlanta, made mention of the recent announcement of the Virtex 7 architecture. My colleagues and I assumed that either the announcement was very recent or not very well publicized as none of us had heard anything official regarding Virtex 7. A subsequent web search returned little except for a white paper on 28nm technology. Does anyone know what announcement the CTO was referring to?Article: 147253
In message <1771ba54-e12f-44ba-af73-1cebb0cb2182@11g2000yqr.googlegroups .com>, Derek Simmons <dereks314@gmail.com> writes >On Apr 19, 9:53 am, "Smith" <sm...@donotwantmail.com> wrote: >> Hello all >> >> I need to run an old firmware for a Siemens SAB 80C537 microcontroller unit >> (MCU). The MCU is now obsolete (it's from the late 1980s). >> >> The firmware is compiled from several thousand rows of assembly language. It >> would take a long time to understand the code and re-program it in C. >> >> So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware >> code without any changes to the code. >> >> Any one here had any luck with this kind of problem? > >The 8031/8051 architecture or compatible MCUs are still being used. >When I was at KODAK it was used in a couple of different parts of a >minilab system for controlling and synchronizing motors. I recently >interviewed with a avionics company that uses it for digital displays >in the cockpit of the plane (it is easy to get certfied for the FAA). > >Don't write it off yet... There are some 500 variants based on over 40 different cores. Whilst it is relatively easy to move C it will be a real dog to moves assembler. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/Article: 147254
I received a Sigasi Editor update email which had the following statement: "Xilinx no longer ships ModelSim with ISE but now ships its own HDL simulator that enables functional and timing simulations for VHDL, Verilog and mixed VHDL/Verilog designs: ISim." Is this correct? Although ISIM is not bad it is still a long way from being Modelsim (even though the MXE(starter) edition is fairly limited), Hans www.ht-lab.comArticle: 147255
Chris H schrieb: >>The 8031/8051 architecture or compatible MCUs are still being used. >>When I was at KODAK it was used in a couple of different parts of a >>minilab system for controlling and synchronizing motors. I recently >>interviewed with a avionics company that uses it for digital displays >>in the cockpit of the plane (it is easy to get certfied for the FAA). >> >>Don't write it off yet... > > There are some 500 variants based on over 40 different cores. Whilst it > is relatively easy to move C it will be a real dog to moves assembler. It does depend on programming /style/ more than on programming /language/. If the device-related code (peripherals, special functions) is spread over all sources, with inline access/instructions and not commented, it's *much* work regardless of language. If the code is well structured and commented, with modules dedicated to clearly defined tasks, it's not really a problem - also regardless of language. TilmannArticle: 147256
>> The point is that if you don't do static timing analysis (or have an >> analyzer that is broken) timing verification is nearly impossible. > > And even if you do, the device might still have timing problems. Can you expand on this Glen? As I have always understood it one of the bedrocks of FPGA design is that when it's passed a properly constrained static timing analysis an FPGA design will always work (from a timing point of view). Nial.Article: 147257
On Apr 20, 1:00=A0pm, Eric <eric.lafor...@gmail.com> wrote: > Hi All, > > I've recently published a paper exploring how to implement memories > with multiple read and write ports on existing FPGAs. I figured it > might be of interest to some. > > Summary, paper, slides, and example code are here:http://www.eecg.utoront= o.ca/~laforest/multiport/index.html > > There are no patents or other additional IP encumbrances on the code. > If you have any comments or other feedback, I'd like to hear it. > > Eric LaForest > PhD student, ECE Dept. > University of Torontohttp://www.eecg.utoronto.ca/~laforest/ Could you mention here or on your page what you mean by "multipumping?" If you mean time multiplexed access, I can see why multipumping is bad. [The "pure logic" approach also isn't obvious.] Do you update the LVT in the same way I might update the RAM value in a many-write BlockRAM? To implement a many-write BlockRAM, each "write bank" is maintained separately. To write a new value, only the write bank for the associated write port is updated but with the XOR of the write data with the reads for all the other write banks at the same address. By reading the same address from all write banks, the XOR of all the reads is the most recent write value (unless there are multiple writes in the same clock cycle). Since the LVT only has to be as wide as the number of entries, I can see how this would be very beneficial for wide data and many write ports. Aside from wide data, however, I don't see (without going into the attachments on that page) how updating the LVT is any different than updating the memory in the first place.Article: 147258
In message <hqmfbt$g77$1@news.eternal-september.org>, Tilmann Reh <usenet2007nospam@autometer.de> writes >Chris H schrieb: > >>>The 8031/8051 architecture or compatible MCUs are still being used. >>>When I was at KODAK it was used in a couple of different parts of a >>>minilab system for controlling and synchronizing motors. I recently >>>interviewed with a avionics company that uses it for digital displays >>>in the cockpit of the plane (it is easy to get certfied for the FAA). >>> >>>Don't write it off yet... >> >> There are some 500 variants based on over 40 different cores. Whilst it >> is relatively easy to move C it will be a real dog to moves assembler. > >It does depend on programming /style/ more than on programming /language/. > >If the device-related code (peripherals, special functions) is spread >over all sources, with inline access/instructions and not commented, >it's *much* work regardless of language. > >If the code is well structured and commented, with modules dedicated to >clearly defined tasks, it's not really a problem - also regardless of >language. For a high level language I would agree but we are discussing "several thousand rows of assembly language". For most 8051 code the C will be the same for the core and it is only the peripherals that are different. Most of the other stuff like memory allocation and SFR's etc will be handled by the compiler. A recompile with a different 8051 target selected will solve many of the problems. With Assembler you can't do that. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/Article: 147259
In comp.arch.fpga Nial Stewart <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote: >>> The point is that if you don't do static timing analysis (or have an >>> analyzer that is broken) timing verification is nearly impossible. >> And even if you do, the device might still have timing problems. > Can you expand on this Glen? > As I have always understood it one of the bedrocks of FPGA design > is that when it's passed a properly constrained static timing > analysis an FPGA design will always work (from a timing point of view). Well, some of the comments were regarding ASIC design, where things aren't so sure. For FPGA designs, there is, as you say, "properly constrained" which isn't true for all design and tool combinations. One that I have heard of, though haven't actually tried, is having a logic block where the delay is greater than one clock cycle, but less than two. Maybe some tools can do that, but I don't believe that all can. -- glenArticle: 147260
On Apr 21, 4:19=A0am, "HT-Lab" <han...@ht-lab.com> wrote: > I received a Sigasi Editor update email which had the following statement= : > > "Xilinx no longer ships ModelSim with ISE but now ships its own HDL simul= ator > that enables functional and timing simulations for VHDL, Verilog and mixe= d > VHDL/Verilog designs: ISim." > > Is this correct? > > Although ISIM is not bad it is still a long way from being Modelsim (even= though > the MXE(starter) edition is fairly limited), > > Hanswww.ht-lab.com Interesting. Altera is taking exactly the opposite approach. The first time I started Quartus II v9.1 SP1 I got a message that said their native simulator would not be included "in future versions" of the software. Talking with my FAE, he stated that starting with version 10.0 only ModelSim-Altera would be included. --MarcArticle: 147261
On Apr 21, 12:38=A0am, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 20, 5:14=A0pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:
>
>
>
> > On Apr 20, 11:46=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> > > > >http://sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf
>
> > > > The infamous Guideline #5 bans variable semantics from always block=
s
> > > > with sequential logic. It must be the Worst Guideline ever for RTL
> > > > designers.
> > > > The result is not wizardry but ignorance.
>
> > > > How are we supposed to "raise the abstraction level" if Verilog RTL
> > > > designers
> > > > can't even use variables?
>
> > > I didn't notice this post until today. =A0I think you are completely
> > > misreading the guidelines if you think they mean "Verilog RTL
> > > designers can't even use variables"
>
> > I use that line as a shorthand for "Guideline #5 combined with
> > Guideline #1, if taken seriously, forbids the use of traditional
> > variable semantics provided by blocking assignments, in the
> > context of a clocked always block".
>
> > No matter how absurd I hope this sounds to you, that's really
> > what it says.
>
> Well, the guidelines absolutely _do_ "forbid the use of traditional
> variable semantics provided by blocking assignments, in the context of
> a clocked always block", but I don't think that translates into
> "Verilog RTL designers can't even use variables."
>
> What it *does* translate into is "The cleanest way to write Verilog is
> somewhat verbose, in that it requires you to separate your
> combinatorial logic from your sequential logic."
>
> Basically, this method of thinking/coding requires two variables for
> each sequential variable. =A0It's really handy to have a nice naming
> convention, like next_x is the variable that will be placed into x on
> the next clock.
>
> So you have your definitions:
>
> reg =A0 =A0 =A0 y, =A0next_y;
> reg [5:0] x, =A0next_x;
>
> and your combinatorial block:
>
> always @* begin
> =A0 =A0 next_x =3D x + 1;
> =A0 =A0 next_y =3D x =3D=3D 0;
> end
>
> and your sequential block:
>
> always @(posedge clk or negedge rstn)
> =A0 =A0 if (!rstn) begin
> =A0 =A0 =A0 =A0 x <=3D 0;
> =A0 =A0 =A0 =A0 y <=3D 0;
> =A0 =A0 end else begin
> =A0 =A0 =A0 =A0 x <=3D next_x;
> =A0 =A0 =A0 =A0 y <=3D next_y;
> =A0 =A0 end
>
> The declaration of registers and the sequential block both become,
> pretty much, boilerplate code with this method of coding -- all the
> action happens in the combinatorial block. =A0I am actually, slowly, in
> my spare time, working on a project that will create a lot of the
> boilerplate for coding in this method.
>
> How does this help? =A0It's more about a human's ability to mentally
> manage complexity than anything else. =A0In the sequential block, every
> line must be 'xxx' <=3D next_'xxx'. =A0Very easy to verify. =A0In the
> combinatorial block, 'next_' must appear on the lhs, and only on the
> lhs, of any assignment involving a sequential variable. =A0Nothing keeps
> you from using if, case statements, etc. in the combinatorial block,
> and it's very easy to think about, because you see two variables
> simultaneously -- what is 'x' right now, and what will 'x' be after
> the next clock.
>
> I have worked at several companies and with several individuals where
> this coding style is used. =A0I did not invent it; as far as I know it
> was probably invented at multiple places independently. =A0It works
> quite well, but is, as I mentioned, a bit verbose. =A0There is no reason
> to use it for extremely simple modules, but OTOH, the breakover point
> where it is better to use it comes much sooner than you might think.
Thanks for explaining your coding style details, that's much
more enlightening than philosophical discussions.
I stand by my quote. The context was clearly "using variables to
raise the abstraction level". That's not what this does.
Your coding style provides a very verbose workaround for temporary
variables. I just can't imagine this is how you do test benches, that
are presumably much more complex than your RTL code. Presumably
there you use temporary variables directly where you need them without
great difficulty. Why would it have to be so different for
synthesizable
RTL?
You refer to a "mental model" to manage complexity. To your credit,
you provide an argument, something the original author of
guideline #5 never did. However, I find it dubious. To manage
complexity,
I don't need to see the hardware registers, complete with Q and D,
so explicitly in the code. I think I understand pretty well what kind
of
coding styles are efficiently supported by synthesis tools. Given
this,
I try to write the code itself as clearly as possible.
Most importantly: your coding style doesn't support non-temporary
variables. In other words, register inferencing from variables is not
supported and therefore ignored as technique. In this sense, this is
actually a good illustration of the point I'm trying to make.
I happen to think that register inferencing from variables is an
essential tool. It raises the abstraction level just one notch. The
registers are not glancing at you from the code (although
unambiguously defined) but in return your coding style can be
much more expressive.
Jan
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com
Article: 147262On Wed, 21 Apr 2010 09:19:10 +0100, HT-Lab wrote: > I received a Sigasi Editor update email which had the following > statement: > > "Xilinx no longer ships ModelSim with ISE but now ships its own HDL > simulator that enables functional and timing simulations for VHDL, > Verilog and mixed VHDL/Verilog designs: ISim." > > Is this correct? > > Although ISIM is not bad it is still a long way from being Modelsim > (even though the MXE(starter) edition is fairly limited), > > Hans > www.ht-lab.com Has anyone here tried the Xilinx simulator? How is it's performance relative to commercial simulators? Modelsim Starter is severely crippled so it wouldn't be a particularly hard task to produce a simulator that out performs it. Both Xilinx and Altera of produced synthesis tools that are competitive with Synplify, it would be interesting if Xilinx had ambitions to produce a simulator that was as fast as Questa, or better yet as fast as NCsim.Article: 147263
On Apr 21, 8:19=A0am, Jan Decaluwe <j...@jandecaluwe.com> wrote: > Thanks for explaining your coding style details, that's much > more enlightening than philosophical discussions. > > I stand by my quote. The context was clearly "using variables to > raise the abstraction level". That's not what this does. I didn't show any variables raising the abstraction level, no, but I showed a context they could be provided in. > Your coding style provides a very verbose workaround for temporary > variables. I just can't imagine this is how you do test benches, that > are presumably much more complex than your RTL code. Presumably > there you use temporary variables directly where you need them without > great difficulty. Why would it have to be so different for > synthesizable > RTL? You're right. Testbenches do not suffer from this limitation. But, in point of fact, I can use any sort of logic in my testbench. I use constructs all the time that aren't realistically synthesizable, so comparing how I code synthesizable RTL vs how I code testbenches would turn up a lot more differences than just this. > You refer to a "mental model" to manage complexity. To your credit, > you provide an argument, something the original author of > guideline #5 never did. However, I find it dubious. To manage > complexity, > I don't need to see the hardware registers, complete with Q and D, > so explicitly in the code. I think I understand pretty well what kind > of > coding styles are efficiently supported by synthesis tools. Given > this, > I try to write the code itself as clearly as possible. Yes, but when you use if/else, or case statements, or other complex structures, it is easy to get lost. Humans can only hold a very few things in their minds at a time, and this is a powerful tool. As I said, I certainly did not invent this style, but I personally know dozens of people who use it, and I have personally introduced it to at least 3 people, and they all find it extremely useful. > Most importantly: your coding style doesn't support non-temporary > variables. In other words, register inferencing from variables is not > supported and therefore ignored as technique. In this sense, this is > actually a good illustration of the point I'm trying to make. Well, it may be a good illustration to you, but now you're waxing philosophical again. Care to show an example (preferably in verilog) of how not using this coding style supports your preferred technique? > I happen to think that register inferencing from variables is an > essential tool. It raises the abstraction level just one notch. The > registers are not glancing at you from the code (although > unambiguously defined) but in return your coding style can be > much more expressive. I am actually doing something similar, I think, in my verilog automagic boilerplate code, which can determine size and type of registers in most cases, and automatically declares them. Regards, PatArticle: 147264
Any information in this regard will be really appreciated. > >I guess Xilinx also uses R2^2SDF --- because they have scaling for every >pair of radix 2 butterflies. > >> >>Altera clearly mentions that their pipelined FFT core uses R2^2SDF >>architecture. >>But I could not find any such info about Xilinx -- can anyone help? >> >>Onkar >> >>>Hi, >>> >>>Can anyone tell me whether the Xilinx Pipelined FFT arch uses R2SDF or >>>R2^2SDF? >>> >>>Regards, >>>Onkar >>> >>> >>> >>>--------------------------------------- >>>Posted through http://www.FPGARelated.com >>> >> >>--------------------------------------- >>Posted through http://www.FPGARelated.com >> > >--------------------------------------- >Posted through http://www.FPGARelated.com > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147265
We finally made an assembly slot and built the 4 remaining Polmaddie CPLD and FPGA boards. These very low cost CPLD and FPGA boards will sell to universities and colleges in prices as low as $30-40. One off pricing starts at $60-70. The concept is a bit different to that offered by most development board vendors and we have 5 solutions, from 4 different CPLD/FPGA vendors, allowing you to evaluate differnt tool flows or even different technologies with a common feature set. More details http://www.enterpoint.co.uk/polmaddie/polmaddie_family.html. Polmaddie1 is shipping already. Polmaddie 3 should start shipping next week. Polmaddie2 should be shipping next. We are doing a low cost USB programmer for this board and that is a 2-3 weeks away. Polmaddie4 and Polmaddie5 will be a little longer as we need to do some work on low cost programming solutions for them. John Adair Enterpoint Ltd.Article: 147266
On Apr 20, 6:20=A0pm, "stephen.cra...@gmail.com" <stephen.cra...@gmail.com> wrote: > The CTO of Xilinx, during his keynote this morning at the > Reconfigurable Architectures Workshop in Atlanta, made mention of the > recent announcement of the Virtex 7 architecture. =A0My colleagues and I > assumed that either the announcement was very recent or not very well > publicized as none of us had heard anything official regarding Virtex > 7. A subsequent web search returned little except for a white paper on > 28nm technology. > > Does anyone know what announcement the CTO was referring to? Either your colleagues misheard what was said our our CTO, Ivo Bolson, mispoke. There has been no announcement of a Virtex-7 FPGA family. Xilinx did recently announce aspects of future families that will be developed on the 28nm process node. http://www.xilinx.com/technology/roadmap/index.htm Ed McGettigan -- Xilinx Inc.Article: 147267
On Apr 21, 1:19=A0am, "HT-Lab" <han...@ht-lab.com> wrote: > I received a Sigasi Editor update email which had the following statement= : > > "Xilinx no longer ships ModelSim with ISE but now ships its own HDL simul= ator > that enables functional and timing simulations for VHDL, Verilog and mixe= d > VHDL/Verilog designs: ISim." > > Is this correct? > > Although ISIM is not bad it is still a long way from being Modelsim (even= though > the MXE(starter) edition is fairly limited), > > Hanswww.ht-lab.com Xilinx still provides ModelSim XE (Xilinx Edition), http://www.xilinx.com/tools/mxe.htm Ed McGettigan -- Xilinx IncArticle: 147268
Chris H schrieb: >>It does depend on programming /style/ more than on programming /language/. >> >>If the device-related code (peripherals, special functions) is spread >>over all sources, with inline access/instructions and not commented, >>it's *much* work regardless of language. >> >>If the code is well structured and commented, with modules dedicated to >>clearly defined tasks, it's not really a problem - also regardless of >>language. > > For a high level language I would agree but we are discussing "several > thousand rows of assembly language". Even with several ten thousands rows of assembler that needs not be a problem. BTDT. It's a matter of structure and documentation. (I am still doing many projects completely in assembler.) > For most 8051 code the C will be the same for the core and it is only > the peripherals that are different. Most of the other stuff like memory > allocation and SFR's etc will be handled by the compiler. A recompile > with a different 8051 target selected will solve many of the problems. > With Assembler you can't do that. Even with C you need to access the SFRs (ports, peripherals) somehow. If these accesses are splattered across the whole sources, it doesn't matter if it's C or assembler. Memory allocation is normally uncritical, since that is easily portable between many similar derivatives. Of course, if you previously had a device with large XRAM (being used indeed) and try to port that to a smaller chip, you'll run into problems... But again, in this case C wouldn't help you either. Basically, the part that you can leave unchanged with C, is the same part that you can leave unchanged with assembler. TilmannArticle: 147269
Hello everyone, I'm trying to synthesise my design using Synplify Pro D-2010, but I am new to this tool and encountering various problems. Here's my first one, which I'd like to solve to be able to investigate other mysterious errors I'm getting. In my design, I use a package called "types_viterbi". In my VHDL files, I access this package by using the classic "use work.types_viterbi.all" line of code. The file containing this package is added to my Synplify project. I see it under the VHDL folder in the GUI shown when accessing my .prj file. Except, when I try to do a "Synthax Check" or a "Synthesis Check" of my components, Synplify returns a warning saying it cannot find "types_viterbi". So, of course, it cannot find the constants I've declared in this package, which is the error shown below. Here's the exact warning & error returned by Synplify: @W: CD643 :"U:\Recherche\Algo_Viterbi_Parallele\VHDL\Synplify\source\decodeur_viterbi_carre.vhd":11:21:11:21|Ignoring use clause - types_viterbi not found ... @E: CD255 :"U:\Recherche\Algo_Viterbi_Parallele\VHDL\Synplify\source\decodeur_viterbi_carre.vhd":15:42:15:42|No identifier "poids_size" in scope I've read the documentation related to the compiler warning CD643, and it says nothing about user-defined packages. However, in the Synplify documentation on Libraries and Package, there's the following information : If you create your own package and compile it into the work library to access its definitions, you still need a use clause before the entity using them, but not a library clause (because work is the default library.) To access packages other than those in work and std, you must provide a library and use clause for each package as shown in the following example of creating a resource library. Is there a step I must do to compile my package into the work library? I've tried selecting the "types_viterbi.vhd" file and running the "Compile Only/F7" command, but this compiles the top_level entity. I did another Check Syntax of the top level entity after, and I still got the warning & error. Yet, the compile command worked! I haven't tried compiling my package into a separate library. It would involve changing all of my VHDL files to include this new library and I'd rather just have access to my package from the work library. Any help clarifying this problem is welcomed. Again, I'm new to this tool, so it may be a very simple solution, but I can't find anything in their documentation or on a Google search. Sincerly, Isabelle LaRoche Université Laval --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147270
I will use Intel StrataFlash Parallel NOR Flash PROM to store two . bit files I have been able to generate the two files. prm &. mcs after having 1) prepare a PromFile. 2) Prom supporting multiple Design versions . 3) Adding the first and the second Bitsream bitsream after that I want to configure the parallel Prom but I can not make it? is what I have to configure the FPGA as or NO?? ... Can someone help me??? thank you in advance .. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147271
On Apr 21, 10:59=A0am, John Adair <g...@enterpoint.co.uk> wrote: > We finally made an assembly slot and built the 4 remaining Polmaddie > CPLD and FPGA boards. These very low cost CPLD and FPGA boards will > sell to universities and colleges in prices as low as $30-40. One off > pricing starts at $60-70. > > The concept is a bit different to that offered by most development > board vendors and we have 5 solutions, from 4 different CPLD/FPGA > vendors, allowing you to evaluate differnt tool flows or even > different technologies with a common feature set. > > More detailshttp://www.enterpoint.co.uk/polmaddie/polmaddie_family.html. > > Polmaddie1 is shipping already. Polmaddie 3 should start shipping next > week. Polmaddie2 should be shipping next. We are doing a low cost USB > programmer for this board and that is a 2-3 weeks away. Polmaddie4 and > Polmaddie5 will be a little longer as we need to do some work on low > cost programming solutions for them. > > John Adair > Enterpoint Ltd. I didn't see which Spartan-3 is on the Polmaddie 3. Thanks, PatArticle: 147272
It is a XC3S50AN on the Polmaddie3 so it's quite a useful board even beyond the target of the educational market. It's my personal favourite of the 5 boards but they all have different things to show. It is worth saying all of these boards can be powered from the USB port and the jack on board is just for convenience. John Adair Enterpoint Ltd. On 21 Apr, 19:44, Patrick Maupin <pmau...@gmail.com> wrote: > On Apr 21, 10:59=A0am, John Adair <g...@enterpoint.co.uk> wrote: > > > > > We finally made an assembly slot and built the 4 remaining Polmaddie > > CPLD and FPGA boards. These very low cost CPLD and FPGA boards will > > sell to universities and colleges in prices as low as $30-40. One off > > pricing starts at $60-70. > > > The concept is a bit different to that offered by most development > > board vendors and we have 5 solutions, from 4 different CPLD/FPGA > > vendors, allowing you to evaluate differnt tool flows or even > > different technologies with a common feature set. > > > More detailshttp://www.enterpoint.co.uk/polmaddie/polmaddie_family.html= . > > > Polmaddie1 is shipping already. Polmaddie 3 should start shipping next > > week. Polmaddie2 should be shipping next. We are doing a low cost USB > > programmer for this board and that is a 2-3 weeks away. Polmaddie4 and > > Polmaddie5 will be a little longer as we need to do some work on low > > cost programming solutions for them. > > > John Adair > > Enterpoint Ltd. > > I didn't see which Spartan-3 is on the Polmaddie 3. > > Thanks, > PatArticle: 147273
Does it simulate OK? Sometimes the files need to be added in correct order, i.e. the file with the package must be added before any library units that make use of it. IIRC you can drag them around in the gui to alter the order, or check the .prj file which should have lines such as: add_file -lib work my_pkg.vhd add_file -lib work my_ent.vhd etc. HTH -- PontusArticle: 147274
"HT-Lab" <hans64@ht-lab.com> writes: > Although ISIM is not bad it is still a long way from being Modelsim (even though > the MXE(starter) edition is fairly limited), I dunno, but I was still able to download the latest Modelsim MXE from Xilinx today, version 6.4b from 04/06/2009. But considering it's fairly old, maybe it's true. I'm sure Xilinx is very happy if they can stop stuffing Mentor's coffers and ship their own ISIM instead.
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