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
Its MiroTech.. They look down for the count.. Steve http://www.mirotech.comArticle: 49551
Rick Filipkiewicz wrote: > snip > > (*) I question I've always wanted to know the answer to here. Why is it so > common to see this sort of thing: > > `ifdef VCS > // ... some comment about avoiding a race condition ... > #1 > `endif some thing like this .. http://www.deepchip.com/items/0393-04.html -Lasse -- // Lasse Langwadt Christensen // Aalborg, DanmarkArticle: 49553
Yikes, you guys are scaring me. Hope these '#1' designers aren't doing safety
critical stuff.
Las--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 49554
Thinking further along these lines, are there any tips for writing
*large* PLA's for FPGA's? I currently have to target 31 inputs, 260
minterms and 85 outputs to a Virtex-II. The inputs are sufficiently
scattered that it is impractical to partition it & use Block RAMs.
Currently, I use mechanically generated code thus:
LIBRARY ieee ;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_arith.all;
USE ieee.std_logic_unsigned.all;
USE ieee.std_logic_misc.all;
ENTITY placore IS
PORT(
CUR : in unsigned(30 downto 0);
PLAOUT : out unsigned(84 downto 0) );
END placore ;
architecture generated of placore is
function INSTR ( -- Generate the AND-plane
output
signal ISSUED : unsigned; -- PLA input
constant MASK, VALUE : unsigned) -- Mask, & resulting value
return boolean is
begin
return (ISSUED and MASK) = VALUE;
end INSTR;
begin
mpla: process (CUR)
variable ANS : unsigned(PLAOUT'range); -- Accumulates the OR-plane
-- result
variable HIT : natural; -- Count PLA "hits"
-- Note: This code is mechanically generated from a PLA listing.
-- Each IF block corresponds to one PLA term.
begin -- process mpla
HIT := 0;
ANS := (others => '0');
if INSTR(CUR,"0001000000000011111111110000001",
"0000000000000000001000000000000") then
ANS := ANS or
"0000000010000000000000000000010000000000010000100100000000100000000000000000000111000";
HIT := HIT + 1;
end if;
-- 250 more terms, similarly
if INSTR(CUR,"0010000000000011111111111100111",
"0010000000000001111111111000111") then
ANS := ANS or
"0000000000000000000000000000100001000000000000100000000000000000000000000000000000000";
HIT := HIT + 1;
end if;
PLAOUT <= ANS; -- Export the OR-plane
-- result
assert (HIT = 1) or (now < 5 ns); -- Sanity check
-- (ignored by synthesis)
end process mpla;
end generated;
This works (but is very slow to synthesise) with around 50 minterms,
however the full design causes XST to run out of memory. Database
Answer #15336 mentions this memory problem, but doesn't offer a
solution.
I can work around, by partitioning the PLA into 5 sections, and then
OR-ing their outputs, but it's pretty unwieldy. Is there a better way?
phil_j_connor@hotmail.com (Phil Connor) wrote:
:"Justin A. Kolodziej" <jkolodzi@students.uiuc.edu> wrote in message news:<Pine.GSO.4.31.0211111730001.3254-100000@ux13.cso.uiuc.edu>...
:> Does anyone have a pointer to a canonical list of things to do and avoid
:> doing when you want to write VHDL that has a good chance of actually
:> synthesizing correctly in Leonardo?
:>
:> I only know that what I do tends to work better than what my students do
:> (I have the unfortunate task of TAing a class in embedded systems and
:> reprogrammable logic), but I admit that I don't have such a list of rules
:> that will guarantee that VHDL works when it is synthesized, even if it
:> works in simulation.
:>
:> Certainly someone out there must have a list... and I don't mean the
:> "Synthesizable VHDL" subset, because even if the synthesis tools gives no
:> warnings or anything, things can break horribly when additional processes
:> are added, it seems.
:
:Hi Justin,
:
:Isn't it just a case of the VHDL having to match the software
:interpreting it, that is the synthesis tool.
:
:Packages like FPGA Express have a large manual telling you how to
:write VHDL that will be correctly synthesised. A wise person would
:follow these templates religiously.
:
:However easy to remember rules of thumb are more interesting and
:memorable.
:
:Good question!
:
:Regards
:
:Phil
Article: 49555Ick! Maybe an alias will help to define and assign the bit fields? Just a thought. CRS David R Brooks wrote: > Thinking further along these lines, are there any tips for writing > *large* PLA's for FPGA's? I currently have to target 31 inputs, 260 > minterms and 85 outputs to a Virtex-II. The inputs are sufficiently > scattered that it is impractical to partition it & use Block RAMs. > > Currently, I use mechanically generated code thus: > > LIBRARY ieee ; > USE ieee.std_logic_1164.all; > USE ieee.std_logic_arith.all; > USE ieee.std_logic_unsigned.all; > USE ieee.std_logic_misc.all; > > ENTITY placore IS > PORT( > CUR : in unsigned(30 downto 0); > PLAOUT : out unsigned(84 downto 0) ); > END placore ; > > architecture generated of placore is > > function INSTR ( -- Generate the AND-plane > output > signal ISSUED : unsigned; -- PLA input > constant MASK, VALUE : unsigned) -- Mask, & resulting value > return boolean is > begin > return (ISSUED and MASK) = VALUE; > end INSTR; > > begin > > mpla: process (CUR) > variable ANS : unsigned(PLAOUT'range); -- Accumulates the OR-plane > -- result > variable HIT : natural; -- Count PLA "hits" > > -- Note: This code is mechanically generated from a PLA listing. > -- Each IF block corresponds to one PLA term. > > begin -- process mpla > HIT := 0; > ANS := (others => '0'); > > if INSTR(CUR,"0001000000000011111111110000001", > "0000000000000000001000000000000") then > ANS := ANS or > "0000000010000000000000000000010000000000010000100100000000100000000000000000000111000"; > HIT := HIT + 1; > end if; > > -- 250 more terms, similarly > > if INSTR(CUR,"0010000000000011111111111100111", > "0010000000000001111111111000111") then > ANS := ANS or > "0000000000000000000000000000100001000000000000100000000000000000000000000000000000000"; > HIT := HIT + 1; > end if; > > PLAOUT <= ANS; -- Export the OR-plane > -- result > > assert (HIT = 1) or (now < 5 ns); -- Sanity check > -- (ignored by synthesis) > end process mpla; > > end generated; > > This works (but is very slow to synthesise) with around 50 minterms, > however the full design causes XST to run out of memory. Database > Answer #15336 mentions this memory problem, but doesn't offer a > solution. > I can work around, by partitioning the PLA into 5 sections, and then > OR-ing their outputs, but it's pretty unwieldy. Is there a better way? > > phil_j_connor@hotmail.com (Phil Connor) wrote: > > :"Justin A. Kolodziej" <jkolodzi@students.uiuc.edu> wrote in message news:<Pine.GSO.4.31.0211111730001.3254-100000@ux13.cso.uiuc.edu>... > :> Does anyone have a pointer to a canonical list of things to do and avoid > :> doing when you want to write VHDL that has a good chance of actually > :> synthesizing correctly in Leonardo? > :> > :> I only know that what I do tends to work better than what my students do > :> (I have the unfortunate task of TAing a class in embedded systems and > :> reprogrammable logic), but I admit that I don't have such a list of rules > :> that will guarantee that VHDL works when it is synthesized, even if it > :> works in simulation. > :> > :> Certainly someone out there must have a list... and I don't mean the > :> "Synthesizable VHDL" subset, because even if the synthesis tools gives no > :> warnings or anything, things can break horribly when additional processes > :> are added, it seems. > : > :Hi Justin, > : > :Isn't it just a case of the VHDL having to match the software > :interpreting it, that is the synthesis tool. > : > :Packages like FPGA Express have a large manual telling you how to > :write VHDL that will be correctly synthesised. A wise person would > :follow these templates religiously. > : > :However easy to remember rules of thumb are more interesting and > :memorable. > : > :Good question! > : > :Regards > : > :PhilArticle: 49556
"fireball" <sensen@swirvemail.com> wrote in message news:ee7a3b8.22@WebX.sUN8CHnE... > first of all, thanks everyone for your valuable insights. > > equation: AX=B > A 3x3 > X 3x1 > B 3x1 > > Maybe i was wrong in implementing LU decomposition. So i try to write it down in the normal way of solving the matrix inverse by first calculating the cofactors of each, taking the adjoin matrix and divide by the determinant. Finally, i multiply it with the B on the RHS. > > i dont' have experience in writing HDL so i started with verilog. But i have problems with the dividing part, any suggestions? it say error:Xst:870 Can not use the DIV > > Anyone done this before? or anyone know any useful website which has a collection of verilog examples be it matrix, arithmetic? Synopsys will not create a divider for you, you'll have to design it yourself. If you do not need a lot of precision, I once did division by inversion and multiplication, and did inversion with a table lookup. I created the table by writing a C program to create the verilog, then synthesized it as gates. My table inverted a 9-bit mantissa and produced a 9-bit quotient for use as a multiplier. The propagation delay was about 6 or 7 gates, I think, and the total gate count was something like 1000 gates. If you're using an FPGA with on-chip memory, you might do the inversion with a RAM. In the Virtex 2 family, you can have a 10-bit mantissa using a RAm in 1Kx18 mode, and only read 10 of the data bits. Another trick that might work for you is to use logs. You can use a table to convert, do muls and divs by addition and subtraction, then use a table to convert back. -StanArticle: 49557
It has been awhile since I have looked at any of the numbers for FPGA FF metastability. Can anyone point me to data on the XC2S family, Spartan II? I believe this can be boiled down to a simple graph for a given clock rate product (or input change rate and FF clock rate) and a graph of the particular FFs in question. I know there is also an equation, but a graph is so simple to use and can help to explain it to others. Is there any difference in coefficients between the internal CLB FFs, the shift register FFs, the IOB FFs and any others that I may have missed? Have all of these been characterized for metastability? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 49558
Besides the obvious like power/ground have you checked whether the PGM[2..0] inputs select the page that you programmed your data into? Which page are you using? Which mode are you using to configure your 4 EP20K400 devices? 1-bit passive serial and all data in a chain, 4-bit passive serial loading your devices in parallel or passive parallel synchronous/asynchronous? When you convert your .sof file into an .pof file for the EPC16 there are several options like clock source (internal/external) which in your case probably should be set to internal. Do you use external pull-ups on nCS and OE or are the internal pull-ups enabled? Do you have external pull-ups on the JTAG chain? Wolfgang http://www.elca.de "Charles Braquet" <charles.braquet@mppmu.mpg.de> schrieb im Newsbeitrag news:ar09ag$103a$1@gwdu67.gwdg.de... > Hello, > I have an EPC16 which have to configure 4 FPGA EP20K400. I load my > design in the APC16 using QuartusII through the JTAG interface. I also > verify it, using an other programmer. The signals nInitConf/nConf and > nOE/Status go high but the DClk is not toggling. This state should > occured when the EPC16 doesn't contain design which is in contradiction > which what the programmer tell me. > Why the DClk doesn't run? Could you help me to configure my FPFA through > my EPC16? > Thanks a lot, >Article: 49559
Hi I have to implement fast, asynchronous FIFOs using Celoxica. The targeted speed of the FIFOs is 75 and 120 MHz with a width of 16 bits. I'm using a Virtex-II FPGA. As part of an evaluation process, my superior wants it to be done in "pure" Handel-C i.e. no additional VHDL. I wonder whether that's really possible; due to the fully synchronous and clocked nature of Handel-C, I guess not. I don't see the way to properly generate the asynchronous FULL and EMPTY signals and pass them between the two clock domains (signals and registers can't be shared). Is there any resource on the web or can anyone point me to the right solution? thanks for any hint Bernhard MäderArticle: 49560
Jerry wrote: > iluvfpgas@yahoo.ca (Alfredo) wrote in message news:<afaad421.0211131255.252e949d@posting.google.com>... > > > Is SystemC compatible with System Verilog, Super log, or the like? > 2. It is not, and it is good thing. > <swithing to sarcastic mode> System Verilog and Superlog are miserable > attempts to convert Verilog into something resembling normal programming > or hardware description language. Since Verilog camp zealots are totally > impervious to discussion based on issues, going any further here is pointless. > <back to regular mode> > Interesting how its SystemC and not SystemAda ...Article: 49561
Hi Charles, There has been a know issue in Quartus2.0 with the EPC4 that sounds similar to your problem. Please try the following The solution then was to convert the .sof file into a new .pof file using the compressed mode. (Tools -> Convert Programming files) If the bitstream is not compressed, DCLK never starts, while if it is, evrerything works fine. Hope this helpes. Fredrik Charles Braquet <charles.braquet@mppmu.mpg.de> wrote in message news:<ar09ag$103a$1@gwdu67.gwdg.de>... > Hello, > I have an EPC16 which have to configure 4 FPGA EP20K400. I load my > design in the APC16 using QuartusII through the JTAG interface. I also > verify it, using an other programmer. The signals nInitConf/nConf and > nOE/Status go high but the DClk is not toggling. This state should > occured when the EPC16 doesn't contain design which is in contradiction > which what the programmer tell me. > Why the DClk doesn't run? Could you help me to configure my FPFA through > my EPC16? > Thanks a lot,Article: 49562
Hey Mark,
No worries! As a non-bitter ex-colleague of yours, I'm
interested in who the mysterious Mr. Andrews could be. I hereby give
you permission ;-) to email me on this one occasion! (Joke free mind
you! My company email still works for now!)
We had the Lattice reps in the other day, (thanks mate!) and
my impression of the software and thoughts on the parts matched that
of Marc, the other poster in this thread. I've no experience of the
support, so can't comment.
The hard SONET/SDH bit is neat, but if you've got the HDL IP
for that, it's is easy to reuse in whichever X or A part you want, and
the FPGA resource can be reused for other stuff if you have operating
modes that don't need SONET.
Also, Is it true that the SER bit of the SERDES doesn't meet
the Tx SONET jitter specs? If so, SONET apps would need an external
de-jitter device anyway, so why not use Virtex II pro / Stratix SERDES
features and have higher gate count capability?
later mate, Symsx.
"Mark Smith" <mark.smith@latticesemi.com> wrote in message news:<BqEA9.4299$R5.2396272@nnrp1.ptd.net>...
> Hmmm...Interesting...
>
> It would seem that Mr. Andrews (That's not his name if he's who I think he
> is) is trying to get me in trouble.
>
> juglugs@hotmail.com DOES work for Lattice - It's me...
> Also, Mr. Andrews uses one of my favorite tag lines, (and, apparently the
> same ISP) which gives me some idea as to his identity...
>
> I believe he's a bitter ex-colleague of mine from a previous company.
>
> I mean, honestly, does anyone who actually knows me REALLY think I'd be in
> front of a PC at 9:43 on a Friday evening??? :-)
>
> Symx - Didn't understand your email to begin with - thought you were talking
> about my reply to your Google thing, with which I'd identified myself to
> you.....and no jokes, promise...
>
> Best regards
>
> Mark
>
Article: 49563> Putting registers on the I/O of the design alleviates the need for the > synthesis tools to try to optimize across module boundaries. As we move into > larger devices and get into more of a modular designflow, you'll generally > want to at least register the module outputs, just to maintain consistency > intiming. When you don't have registers, it can be ugly trying to trace a > delay path, and the synthesistools will not be able to optimize through a > module boundary unless both the module and the next levelup are visible at > the time of the compilation. These module boundaries that you are talking about..are you referring to vhdl or verilog modules within the design. If so are you really registering all of your outputs? In a few recent designs I have created a bunch of Bus mux's that let a variety of modules "talk" on one single data bus. Typically on these blocks I neither registered the input or the output of theses signals. I didn't want to incur any latency. I have not run into any timing problems yet, but should I be registering these types of signals?Article: 49564
hello all I am programming XC9536 xl cpld using webpack's impact for the first time. When i programme the cpld it doesnot give any error or warning. But actually i am not achieving the functionality. May be because of wrong pin assignment or some other problem. Can any one of u guide me.Article: 49565
ssbhide@rediffmail.com (suchitra) wrote: >I am programming XC9536 xl cpld using webpack's impact for the first time. >When i programme the cpld it doesnot give any error or warning. >But actually i am not achieving the functionality. >May be because of wrong pin assignment or some other problem. >Can any one of u guide me. Why do you need guiding? Your analysis of the problem is excellent. It most certainly is "because of wrong pin assignment or some other problem".Article: 49566
Ray, It appears you are using your HDL for, more or less, a netlister. I have no problem with parameterized modules, that's the way this stuff SHOULD be done, whether HDL or schematic. It's above that level that I really care about...and personally, I believe schematics (or some graphical interface) is far more functional for most humans to understand/work with. If the HDL synthesizers weren't 10-30 times the cost of the schematic programs, I'd buy part of the argument about tools...and with every new synthesizer, you have to spend time learning it...though the HDL may be portable, the tool operation (and results) isn't. One of the main reasons customers have been asking for HDL designs is because that's what they are being told to do...by who else, the tool and FPGA vendors. It's supposed a selling point, though, only until recently, it really didn't work well at all. For about 5 years I was getting a call per week about how a client was told by "someone" (tool vendor or FPGA vendor) how they had to use synthesis, it would solve all their problems...and so they did...and their design wouldn't get above 10MHz, and wouldn't fit in the part...and I was asked to fix the problem. As you and I have pointed out many times, a tool is only as good as the person using it can make it, and the point is, though you can do netlist design in HDL, the typical user of HDL will not be doing so, and as such, is relying on tool "efficiency" for logic density and speed. Fortunately for the "mainstream" HDL user, the FPGAs are a lot faster and denser, so it hides the foibles of HDL, and the tools have gotten a LOT better in the past three years. To be able to match schematics ability to do critical logic mapping and placement is relatively new to HDL, and yes, that does make it able to match schematics in performance and density ability (for the netlisted logic that is), as you really are not using the synthesizer to do any synthesizing...I guess that's a good thing. I also believe this ability is somewhat tool specific? Are the mapping and placement abilities of HDLs cross tool abilities? Will the highly mapped and placed HDL code used for Synplify work with FPGA Express? That, of course, is a major issue in touting portability if it is not, as you ARE relying on a single vendor for the tool, just like you are with schematic, though not as entirely...as the code can be massaged to "work", but not necessarily as well as it would with the tool it was intended for. Regards, Austin "Ray Andraka" <ray@andraka.com> wrote in message news:3DD2F558.13CA7450@andraka.com... > > > > Austin Franklin wrote: > > > I don't understand. What tools are you talking about? I simply run my > > testbench, written in HDL, same as I would for any design even if the design > > is in HDL, and get the same output waveforms...or better yet, it displays > > the actual signals on the schematics. > > My viewlogic license is only enabled for viewsim and viewdraw. It doesn't > support the viewlogic VHDL, that was extra. Frankly, the Viewlogic VHDL is quite > poor compared to Modelsim or Aldec. > > > What about placement? Problems I've had were the tools didn't allow the use > > of consistent names, either when a change was made with to either the > > design, or the toolset. > > I haven't had much problems with placement, at least not with stuff instantiated > in the code (that is one of the major reasons I do as much structural > instantiation as I do). Only inferred logic changes its names, instantiated > logic generally does not. Inferred flip-flops generally take on the name of the > output net, so there is no problem floorplanning using inferred flip-flops. The > LUTs do tend to get random names, so they are not as easy to deal with in > floorplanning, but then if you do your design with one level of logic, the > mapper packs them with the flip-flops anyway. > > > And what preculdes you from doing that with schematics? Did you ever see > > Philip's tool for generating schematic elements? > > Yes, I did, and it is a very nice tool too. I never did get my own copy because > just as he came out with it I was in the middle of a transition to HDLs. HDLs > give you that capability without having to obtain an add on tool. > > > > > > > > The advantage is if I make a change to the macro, it only gets changed > > > in one place, which is not necessarily true with schematics (using 2 bit > > slices > > > for arithmetic, it is almost true, but you still have the special cases at > > the > > > start and end of a carry chain). The parameterization includes options > > for > > > layout, assignment to different device families (RLOC format for example), > > > automatic signed/unsigned extension, automatic selection of reset vector > > values > > > with the proper FDRE/FDSE etc. These are things that were a little > > awkward with > > > schematics, and are very easy to do with the HDL generates. > > > > Hum, I don't find them awkward at all with schematics, but do with HDLs... > > For example, say you have (this is from a design that I did with schematics) a > bank of 128 129 bit LFSRs. Each is identical except it has a different reset > value. With an HDL, you can construct one parameterized module that generates > the proper combination of sets and resets without ever having to look inside the > module, then you can instantiate those 128 modules in a generate statement that > indexes a constant array (probably in a package in another file so that you > never have to modify the source even if you change the constants) to > parameterize the initial values of each module. If I want to change the intial > values, I just edit the list of initial values, which by the way can be > expressed as binary, decimal, hex, octal or any mix of that you like. With > schematics, you need to generate each module using FDREs and FDSEs. As I > recall, Philips tool didn't do this readily, and it certainly didn't read the > init values out of a common file. Similarly, I can set up filter coefficients > for distributed arithmetic filters as a naturally ordered list of coefficients > in a separate package. My VHDL filter is parameterized to read the coefficients > from a file, process them (with a procedure) to create the init values for the > DA LUTs, and then build the filter including placement. The code is > parameterized for the coefficient width, filter add tree width, bits per clock, > length of the filter etc, and I never have to go inside that module to modify > anything. It took a while to build the library to where I was as productive > with VHDL as I was with schematics, but I am now well past there. > > > Mainstream? Not really. Synplify may be the "tool de Jour", but I don't > > see that as being any better than schematics, though you are locked to a > > single vendor with schematics, no doubt. Also, as you know, every damn > > revision of these HDL compilers generates different code...which reeks havoc > > on some designs. > > Depends on the definition of mainstream, I suppose. Where I come from, > mainstream means that which most people are doing, not what which is 'best'. > When all of my customers are asking for an HDL design flow, I think that can be > described as the mainstream. Schematic entry for FPGA design, like it or not, > can't really be considered mainstream anymore, at least by the definition of > mainstream I am familiar with. You can get around the variations between > compilers by using structural generation for the critical parts of your design. > We do it in a large percentage of each of our designs. As an indicator, I spend > far more time tweaking things for PAR than I do for getting the synthesis to > turn out what I want. > > > > > I agree. Designs I do for my own projects, I do in schematics...simply > > because it keeps the parts cost down, ups the speed significantly...and I > > don't have to wrestle with the tools. I do mostly HDL work for clients now, > > as for misbegotten reasons, they believe it saves them time and money...when > > in every instance, it absolutely, unquestionably does not. > > I'm not sure an HDL will save money or not. Because my library is far more > parameterized than I was able to achieve with schematics, and because I have the > option of structural cosntruction where it matters or RTL level coding where > things are not as critical, my design capture is perhaps a little bit shorter > than it was with schematics. I have seen tremendous gains in the simulation > however because the sophistication of the testbenches is much higher. > > > > > > > > So will I be seeing you in San Jose tomorrow? If so, we can discuss this > > in > > > person. > > > > No, sigh...I am unable to make it, but I was assured by Philip that you > > would defend the fort better than either of us would ;-) > > Depends which fort. I don't defend the schematic fort anymore. I got out of > there right before it burned down around me. As for using a mix of schematics > and HDLs, I find that more awkward than using either...it means maintaining two > libraries, proficiency on additional tools and customers griping louder because > of more tools needed to support a design. You missed a good meeting, They were > very receptive and have been following up this week (which is something we > didn't see before). > > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 49567
This is a multi-part message in MIME format. --------------7D562A6C48D4E41411046FE1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There is now a port of uCOS-II at http://ucos-ii.com/contents/products/ucos-ii/ports-misc.html for Microblaze. Thanks, John Linn John Williams wrote: > Hi folks, > > I am doing some research into the Microblaze architecture - Xilinx doco > states that there is no operating system support - it seems they (for > now) expect microblaze to run a monolithic application. > > I've looked around but not found anything substantial - does anybody > know about any operating system ports to microblaze, either free or > otherwise? I found a press release from Xilinx and Wind River talking > about vxWorks, but no further mention of it on either's website. I'd > love to hear about any budding linux / uClinux / other ports, or indeed > any microblaze developers' mailing lists and resources etc. > > thanks, > > JohnArticle: 49568
Has Xilinx said anything about future versions of WebPack being able to support the 2VP4? It seems a shame that it doesn't support at least one part that actually contains a PowerPC processor. The number of logic cells in the 2VP4 is comparable to those in the largest Spartan IIE part that WebPack supports, so if the criterion is still "marketing gates", the 2VP4 ought to qualify. Oh, wait, how many marketing gates are in a PowerPC? :-)Article: 49569
>John Williams wrote:
>>
>> I am doing some research into the Microblaze architecture - Xilinx doco
>> states that there is no operating system support - it seems they (for
>> now) expect microblaze to run a monolithic application.
>>
>> I've looked around but not found anything substantial - does anybody
>> know about any operating system ports to microblaze, either free or
>> otherwise?
There's a middle ground between a monolithic application and
a traditional operating system. Take a look at uCR
http://icarus.com/ucr/uCR.html
which should run with negligible effort on any processor
targeted by gcc.
- Larry
Article: 49570"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag news:3DD4AEEE.F91B76D3@yahoo.com... > It has been awhile since I have looked at any of the numbers for FPGA FF > metastability. Can anyone point me to data on the XC2S family, Spartan > II? I believe this can be boiled down to a simple graph for a given > clock rate product (or input change rate and FF clock rate) and a graph > of the particular FFs in question. I know there is also an equation, > but a graph is so simple to use and can help to explain it to others. > > Is there any difference in coefficients between the internal CLB FFs, > the shift register FFs, the IOB FFs and any others that I may have > missed? Have all of these been characterized for metastability? Have a look at the latest techXclusive from Peter Alfke, where he provides numbers and graphs for Virtex-IIPRO. As far as I remember there is also a graph with the 4 k Series, so Spartan-II should be somewhere inbetween. -- MfG FalkArticle: 49571
M Schreiber wrote: > These module boundaries that you are talking about..are you referring > to vhdl or verilog modules within the design. Yes, entity/component instances in VHDL speak. > If so are you really > registering all of your outputs? In a few recent designs I have > created a bunch of Bus mux's that let a variety of modules "talk" on > one single data bus. Typically on these blocks I neither registered > the input or the output of theses signals. I didn't want to incur any > latency. I have not run into any timing problems yet, but should I be > registering these types of signals? This thread started about style guidelines for new code, not a critique of working code. Lots of designers use asynchronous processes or things like muxes. If that's how you see it, that's how you should code it. I see muxes as part of a data path that eventually gets to registers. I would put all registers that need the mux into the same entity/module. Variables are handy for doing gating on the D side of the registers. -- Mike TreselerArticle: 49572
Steve, Sorry for that. I will add our synchronous EPP core ( VHDL source) on our Amontec server this week-end. Please visit www.amontec.com by next monday. Regards, Laurent Gauch Steven Derrien wrote: > Hi Laurent, > > Laurent Gauch wrote: > >>Try Chameleon POD on www.amontec.com >> > > > Do you have any specific link ? I have browsed through your website > but I could not find anything related to an EPP vhdl core. > > Thank you, > > StevenArticle: 49573
Bernhard Mäder wrote: > I don't see > the way to properly generate the asynchronous FULL and EMPTY signals > and pass them between the two clock domains (signals and registers > can't be shared). I agree. So try a fast synchronous FIFO. > Is there any resource on the web or can anyone point me to the right > solution? I saw some app notes on celoxica.com. If the boss wants a benchmark, do it in both Handel-C and in an HDL. -- Mike TreselerArticle: 49574
Austin Franklin wrote:
> I also believe this ability is somewhat tool specific? Are the mapping and
> placement abilities of HDLs cross tool abilities?
Is there a schematic file format that crosses tool boundaries?
-- Mike Treseler
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