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
could you sebd me a copy of the file you have ? jdumaresq@cimeq.qc.ca_nospam just remove _nospam to send me this e-mail regards Jonathan "Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> a écrit dans le message de news: 42111c81$0$321$ba620e4c@news.skynet.be... > Hi > > Jonathan Dumaresq wrote: > >> I want to do exactly what you do. but i'm stuck to the netlist problem. > > Glad to know I'm not alone ;) > > >> I use the wb2opb from ascic.ws and now i want to use some opencore ip to >> plug to my microblaze. so if you can send to this ng what you have done >> to >> make it work i'll apreciated > > Well, finally I got a bitstream ! But ... it doesn't work as excpected so > I'm > not sure that what I've done is good. > > So finally I decided to try a smaller problem, just take > Microblaze + UART + opb2wb + opencore_simple_gpio and try to make this > work. > > Here's what I'm trying right now (writing this msg as I'm doing/testing it > ;) > From ground up : > > * First step : Install the opb2wb > -------------------------------- > > - Extract the opb2wb_v1_00_a from the tar.gz and put it into your > personnal pcore dir > - Edit the bbd file and suppress the first column (C_FAMILY) to just leave > the first line > So you should have > > <cut here> > Files > ###########...##### > opb2wb_v1_00_a.edn > <end cut> > > - Edit the mpd file and rename the 'opb_rst' into 'rst' (only the > lowercase one. > leave the OPB_rst untouched ). - Edit the netlist file (.edn) and change > the creator program to "none" > So you have (program "none") instead of (program "xilinx stuff ...") > The ngcbuild don't like to work with edif netlist created by ngc2edit > and tells > you to use the original ngc instead but we don't have it ... > > > *** At this point, adding a opb2wb to an existing/working design and > making all > wb connections external works (I mean you can produce a bitstream. I > don't > know if the wrapper works or not ... **** > > > * Second step : Creating a wb_gpio_simple EDK-compatible core > ------------------------------------------------------------- > > - I've used the simple_gpio core as a base to create my own very simple > gpio_core > ... And I'm still at this step and won't finish tonight ;) > I already send this which may help you. > > > > > Note that some steps might be unecessary, I just wrote that as a > collection of > all the things I made to make it generate a bitstream. > > Sylvain >Article: 79126
Yong Zhu wrote: > Hi Sylvain, > > To make your custom IP accessible in XPS, you'll need to create PSF > conformed directory structure and interface files (PAO/MPD/BBD). The > Create/Import Peripheral Wizard from EDK can help you on this. > > Since you already have the netlist (.ngc) and a wrapper HDL, you > shouldn't have problem to use the wizard's import flow to import your > mac core. After importing, you can use your custom IPs like any other > EDK cores bundled in the tool. > > Let me know if you have any questions regarding the wizard. Hi Yong The main problem we have is not really with XDK. We'd like to use some cores that don't use a opb bus but a wishbone bus. Someone made some wrapper available in the form of EDK core but they seems incompatible with the current EDK. Look at my other post for the details of what correction were necessary. However I have a problem importing a core. Since I don't know verilog I wrote a VHDL file that includes some verilog code and I would like to make this a EDK core. I couldn't find how to do mixed rtl with the wizard so I created a ISE design with my mixed vhdl/verilog design and synthetized it with my main vhdl as top level. I took the ngc file and used the top level vhdl when the wizard asked for the hdl top. But that didn't work exactly like I excpected ... First I'm not sure on how to make the wizard understand 'inout' (bidirectional) ports, there seems to have issue with mysig_T mysig_O mysig_I of which I'm not sure. Second during the bitstream generation I have this error : ERROR:NgdBuild:604 - logical block 'wb_ethermac_0/wb_ethermac_0/maccore' with type 'eth_top' could not be resolved. A Pin name mispelling can cause this, a missing edif or ngc file, or the mispelling of a type name. Symbol 'eth_top' is not supported in target 'spartan 3'. with wb_ether_mac.vhd being my vdhl top file and maccore an instance of eth_top which is defined as verilog. Now, if I also synthetize eth_top as toplevel and copy the resulting ngc file in the implementation directory and relaunch the xflow.bat the XDK left there, it works ... Maybe I'll just learn the verilog basics to do my wrapper in verilog ;) SylvainArticle: 79127
"Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> a écrit dans le message de news: 420fb7ae$0$22479$ba620e4c@news.skynet.be... > Hello, > > I'm trying since yesterday to interconnect the opencore mac to a > microblaze design. > After several problems solved, I'm stuck. > > The "Generate netlist now works fine" but When I try to "Generate > bitstream", > I have three errors from NgdBuild : > > > ERROR:NgdBuild:604 - logical block 'wb2opb_0/wb2opb_0' with type 'wb2opb' > could > not be resolved. A Pin name mispelling can cause this, a missing edif or > ngc > file, or the mispelling of a type name. Symbol 'wb2opb' is not supported > in target > 'spartan 3'. > ERROR:NgdBuild:604 - logical block 'opb2wb_0/opb2wb_0' with type 'opb2wb' > could > not be resolved. A Pin name mispelling can cause this, a missing edif or > ngc > file, or the mispelling of a type name. Symbol 'opb2wb' is not supported > in target > 'spartan 3'. > ERROR:NgdBuild:604 - logical block 'wb_ethermac_0/wb_ethermac_0/maccore' > with > type 'eth_top' could not be resolved. A Pin name mispelling can cause > this, a > missing edif or ngc file, or the mispelling of a type name. Symbol > 'eth_top' is > not supported in target 'spartan 3'. I have the same probleme. I have copied you source code and try to make bitstream and i get the same error. do you have corrected ? I thing his happen because you remoce the C_FAMILY in the bbd file. but i really not shure about this. regards Jonathan > > > For the wb_ethermac core, I've created a file that includes the eth_top of > the > ethernet mac core on opencore and present the interface to the outside > world. > I've done this as a ISE project then I synthetized it to have a .ngc file > (because > I have both VHDL & Verilog there) then I created an IP from this netfile > and my vhdl top file. > > Any one has a clue on what to do ? Has anyone make this work ? (I'm using > ISE/EDK 6.3) > > > Thanks, > > SylvainArticle: 79128
>> Another idea: What do you guys think about adding a slot for a SD Card [1]. >> They are cheap (about EUR 10,- for 128MB) and you get them up to 1GB! >> However, the impact on the board is high: The connector is 'big' and >> increases the board hight. A FPGA with a higher pin-count is needed. For >> the solution without the SD Card a 100pin TQFP would fit, but now a 144pin >> is needed - again a larger board. >> And this adds again a few EUR/$. All these design decissions! You start with >> a minimal core design and than start adding (unnecesssary) features again. >> >> BTW: Has somebody inplemented an SD Card interface in an FPGA. It should >> not be too hard [2]. The simplest solution would be the SPI bus. > > You might want to consider two variants: one that is on the KISS path, > and is on the lower price knee, and just sufficent to operate a workable > JOP, and another that is more maximal, and more able to launch an > operating system as well. I would be happy to go the KISS path, but I don't know how one can keep a soft-cpu module simple to handle. You have too many options: You're developing on two levels: the CPU inside the FPGA with peripheral components and software for the CPU. During development on one of these areas different ways for downloading the configuration/software fits best: Simplest: Flash is configured with JOP waiting for a download of a Java program. How do you donwload it? Via a serial interface - Then we need a serial interface. Program the serial Flash with the Java program. Not very comfortable during development - You have to use Quartus for the Flash programming, but you are only interested in Java development. Now you start changing JOP, e.g. do some FPGA development. Do you want to program the Flash for every try or do you prefere to download the configuration direct to the FPGA. Then we need a second ByteBlaster adapter (one for the Flash and one for the Cyclone). Two pin heads need space and make it more complicate to handle the board (not the KISS path). Any ideas are highly welcome ;-) > > For package, I'd vote against pin-modules, as they are expensive > to make, have a pin count ceiling, and are easily damaged. The only > benefit is they can save a little time in first deployment. > Better are the memory-card formats, as they have low cost and sturdy > connections, that can still be socket managed on 1 & 2 layer PCB, and > you can offer a socket-pcb for users starting from nothing. > First ideas about the memory card format (still SIMM): http://www.jopdesign.com/jopstick/index.jsp One format is very small with a FPGA in TQFP100. There are just enough pins for the SDRAM and the SimmStick bus. The second variant is larger with a TQFP144 FPGA and a slot for a SD card. > Besides the simmmstick itself, you should consider the SODIMM modules, > as seen in TINI : > http://www.maxim-ic.com/products/tini/pdfs/TINI_GUIDE.pdf Yes, another option. However, is there a kind of 'standard' for this larger modules. Are there peripheral modules available for this form factor? > For "smart expansion", SD would be one option, but smaller and > more flexible might be USB-Drive ?. Not as cheap at the lowest node, > but universally portable - few PCs can R/W SD cards, but they can all > R/W a USB drive. > Of course, that means the FPGA needs to be smarter :) Do you mean USB host? That's not so earsy. I would expect that the FPGA (and the software) has to be too smart ;-) Martin PS.: Thanks for all suggestions from the usenet group! It's really fun to discuss several options during development of a board.Article: 79129
Jonathan Dumaresq wrote: >> >>ERROR:NgdBuild:604 - logical block 'wb2opb_0/wb2opb_0' with type 'wb2opb' >>could >>not be resolved. A Pin name mispelling can cause this, a missing edif or >>ngc >>file, or the mispelling of a type name. Symbol 'wb2opb' is not supported >>in target >>'spartan 3'. > > I have the same probleme. I have copied you source code and try to make > bitstream and i get the same error. > > do you have corrected ? Yes, I didn't notice that error because I didn't make a clean between my tried of yesterday and today's. After the generate bitstream failed, copy the .edn file of the opb2wb wrapper into the implementation directory of your edk project and rename it to opb2wb.edn I didn't yet found why this is needed ... it should be done automatically ! (or an equivalent) > I thing his happen because you remoce the C_FAMILY in the bbd file. but i > really not shure about this. Don't think so. Not removing it leads to other problems earlier. And in EDK-wizard generated core the C_FAMILY is not there. SylvainArticle: 79130
Hi Tommy, As far as synthesis or p & r warnings for the code I provided above, I can't recall seeing any. This wasn't a timing critical design, and the code was mainly used to get a quick and dirty measurement of the required clock speed to keep the 7-segment displays lit while multiplexing between the 4 displays. And it was also used to test the multiplexing scheme for the displays. Thanks for the info, JeremyArticle: 79131
And this post helps the engineering community how? "austin" <austin@xilinx.com> wrote in message news:cur6bv$bag1@cliff.xsj.xilinx.com... > Paul, > > I am delighted. > > Not only is the static Iccint current > 7.568 amperes at 100C, but the > device is clearly doing a thermal runaway (in Excel!). > > How did you do that? Does the device melt down just like the > spreadsheet? It looks as if the solution is iterative, and it keeps > trying to converge with the formula for the Iccint being exponetial with > T, and the T just getting hotter, and hotter ...) > > Sure, when the worst case static current is less than the surge, then > there is no "surge...." > > Sure. So if the worst case static is 6 ameres, what is the 'surge' at > 25C? Less than 6 amperes, but still there? > > Smoke and mirrors, mostly smoke? > > You should really check your spreadsheets before posting. > > EP2S180, Industrial, Maximum, no air flow, no heat sink, no logic (0 > power in the blocks), 36 C ambient (runs away, at 35 C ambient it goes > to ~85C. Even a 1/2 degree more causes the Tj to pop to 100+. > > Now, I admit this is a degenerate case, and people will ususally have > some airflow, and maybe even a heatsink. Still ~ 6 amperes just for > static current, but at least it won't melt down. > > At least V4 won't thermally runaway when you turn it on. > > Austin > > Paul Leventis wrote: > > > Hi, > > > > Today we released our updated power specs for Stratix II. Some > > highlights of the updates found in the Stratix II Early Power Estimator > > V2.1 tool: > > > > (1) Reduced static power by up to 47%. We've measured many units from > > across the product family, and have the data to tighten the spec > > compared to our previous conservative/estimated values. The amount of > > change varies from family member to family member, and is a function of > > junction temperature and whether typical or worst-case silicon is > > selected. > > > > (2) Static current on the VccPD rail now reflected (it is tiny) > > > > (3) There is no more in-rush Icc current. The previous current > > reflected a result measured on early units from one family member plus > > some excessive guard-bands. The underlying cause was rectified and all > > Stratix II devices now exhibit a monotonic ramp for Icc and no in-rush. > > > > (4) We previously reported around 100 mA of static power per used MRAM > > in the chip. This turns out to have been a measurement error and now > > there is no added static power. > > > > > > See > > http://www.altera.com/corporate/news_room/releases/products/nr-powerplay.html > > for details on the updates and where to get the EPE. Quartus 5.0 will > > reflect these updated specs when it is released in Q2. > > > > > > Paul Leventis > > Altera Corp. > >Article: 79132
Eric Crabill <eric.crabill@xilinx.com> wrote: > >Hi, > >> Apart from the Xilinx examples I didn't find much in >> the way of resources for the starter kit on the web. > >Please check out http://www.engr.sjsu.edu/crabill for a set >of labs/experiments you can try with the Spartan-3 Starter >kit... I have tried to touch on most of the resources with >the exception of the SRAM. Thanks for the pointer. >// opinion_on > >This kit is well named, a "starter" kit. If everything is >simply handed to you, you don't learn anything. That's why >it makes such a great educational tool. I didn't buy the kit to learn FPGA basics, I bought it as a cheap development platform. I spent about 3 hours pawing through the documentation to write a top level verilog module and matching constraints file which defined all the I/O on the board and expansion connectors. I didn't learn anything it was just tedious and error prone. The only thing I discovered (learnt) writing a hex display module for the 7 segment LEDs was that the anodes have inverting drivers. I wrote the hex display module to use as a diagnostic tool. That is the kind of basic 'IP' which I was disappointed not to find in the box. >If a time multiplexed seven-segment display is challenging >enough for someone to make an appeal to this newsgroup, they >should go through the exercise of designing it themselves. >Maybe with a little help... We are all learners, just at >different places on the path. I think to include resources >like this with the kit itself (or posted to this newsgroup) >defeats its utility as a learning tool. But would enhance its utility as a development platform.Article: 79133
Martin Schoeberl wrote: > I would be happy to go the KISS path, but I don't know how one can keep > a soft-cpu module simple to handle. You have too many options: You're > developing on two levels: the CPU inside the FPGA with peripheral components > and software for the CPU. During development on one of these areas different > ways for downloading the configuration/software fits best: > > Simplest: Flash is configured with JOP waiting for a download of a Java program. > How do you donwload it? Via a serial interface - Then we need a serial interface. > Program the serial Flash with the Java program. Not very comfortable during > development - You have to use Quartus for the Flash programming, but you are > only interested in Java development. > Now you start changing JOP, e.g. do some FPGA development. Do you want to > program the Flash for every try or do you prefere to download the configuration > direct to the FPGA. Then we need a second ByteBlaster adapter (one for the Flash > and one for the Cyclone). Two pin heads need space and make it more complicate > to handle the board (not the KISS path). > > Any ideas are highly welcome ;-) Yes. Indeed at my company we have a design that uses an FTDI FT2232C USB controller to: 1- Power the board (up to 500mA@5V but you can also use external power). 2- Implement a JTAG interface. 3- Implement a serial/FIFO communication line. You get all these from a single cable and that is very useful for development. The FT2232C (http://www.ftdichip.com/Products/FT2232C.htm) implements two versatile IO ports and supports a smart bit-bang mode (MPSSE), so you can do serial or FIFO communications with one channel and JTAG programming or debugging with the other in parallel (you even get some GPIOs that are very handy if you need to configure your board on the fly). We use those 'mini' type-B USB connector that save a lot of space, and you can buy the cables cheap from Palm or mobile phone accessory suppliers. Since you are fond of Java, you might enjoy the Java bindings for the FTDI direct driver at http://jd2xx.dev.java.net/ which I maintain. I have personally implemented an MPSSE JTAG controller using it (tested with Xilinx FPGAs), it is not very difficult. > > Besides the simmmstick itself, you should consider the SODIMM modules, > > as seen in TINI : > > http://www.maxim-ic.com/products/tini/pdfs/TINI_GUIDE.pdf > > Yes, another option. However, is there a kind of 'standard' for this larger modules. > Are there peripheral modules available for this form factor? I guess the DIMM-PC is as standard as it gets (http://www.jumptec.de/product/we_docs/dimm.php). Every vendor seems akin to implement their own standard; besides the world is mostly going high-speed serial now... If you want your own parallel edgeboard connector there are those universal 132-pin AGP connectors that sell for less than a dollar in small quantities... just an idea. > PS.: Thanks for all suggestions from the usenet group! It's really fun to discuss several > options during development of a board. Ain't that GREAT (TM)? At least if you finally mess up you can blame or share the guilt with others :) Luck with you project. -- PabloBleyerKocik / pbleyer / "Their primitive minds couldn't accept the truths." @embedded.cl / -- Cheech Wizard in 'Captured by Morton Frogg'Article: 79134
I'm wondering if anyone could recommend a company who sells single board FPGAs with DSP functionality that has great support and service as well as an extremely reliable product.Article: 79135
Elder Costa wrote:
> >
> > There seem to be various typos in those code snippets you posted-
> > did you cut and paste, or re-type them, into your post?
>
> Cut and pasted.
>
Your attribute example needs underscores in the
label name (U_RAM...) and proper spelling of "lable".
Your first example parses & elaborates OK in VHDL-Simili
if I fix the offending semicolon as follows:
generic (
WRITE_MODE_A : string := "WRITE_FIRST" ;
WRITE_MODE_B : string := "WRITE_FIRST"
);
Other suggestions:
- if you're using unisim.vcomponents, there's no need to
redefine the RAMB16_S2_S4 component here, as it's already
defined in the unisim library
- if using XST, the last few versions of XST understand generics -
you can just use a generic map without the translate on/off stuff,
and skip the attributes. ( See the "Virtex Primitive Support"
section of the XST manual for examples of each method )
- if you still want to use attributes, make sure they match the
generics, or your synth and sim results will differ
Brian
Article: 79136
Hello,
I have a source of extremely stable and clean clock
signal. Its frequency is about 64 MHz. I would like to
use it as the main clock for a Cyclone FPGA chip
(1C6, to be exact). The problem is that the signal
is a sine wave with the amplitude of about 1Vpp.
The exact level is not an issue, I can amplify or attenuate
it appropriately, but the shape bothers me: may I feed
the FPGA clock input with this signal directly? If yes,
then what is the optimal level of the signal? But if this,
unfortunately, is not allowed, then what solution would
you recommend me?
Best regards
Piotr Wyderski
Article: 79137Hmm, Google-Groups-Beta seems to have mangled the four lines of code in my last post unless you use "show options" to display the original message. Anyone out there know how to post/read from Groups-Beta without it auto-mangling code & message text? They've added a "fixed font" selection in the upper right corner of the reader page, which helps, but it still seems to take other liberties that don't show up on the "preview message" display. I also miss the "email me a copy" checkbox of the "old & improved" google-groups posting mechanism. BrianArticle: 79138
Well, John, the issue is "what is the leakage current of the new 90nm technology node?". Xilinx has claimed (and we think we have proved it) that the use of triple oxide (basically keeping memory cells and pass gates at 130 nm in 90nm) gives us both speed, and a 3X leakage advantage. Not to mention an SEU advantage (we haven't even started on that weakness in the competition, yet). They claim that their simpler process is more cost effective (? where are the $ quotes ?) and more producable (we are both shipping), and have similar or better leakage, and better speed. These claims are false. Physics is physics. No smoke and mirrors 6 lut is going to work. They may have solved the surge issue, but we have yet to see any parts where that is true. It is also true they do not make it easy for Xilinx to buy their parts. We are oblidged to pay for them like any customer, so there is a fair and level playing field. So we admit we may not have seen their fixed parts. Have you? The engineering community is a group of very well educated professionals who deserve to know what is going on. Most of them have a sense of humor, and appreciate the banter, some do not. If you are one who does not appreciate my postings, please ignore them. If you objected to the tone of my posting, I am very sorry: I can't help it when I see such total nonsense being presented (IMHO). If the gentlemanly thing to do is to respond in a "proper" fashion (in your humble opinion), then I will leave that to others, as I am not going to live long enough to tolerate such nonsense. Life is far too precious to me to waste. Perhaps if you knew me better you would understand. Since you do not, please feel free to ignore me. Again, my intent is to say it like it is, and not to gloss over the fine points, as it is the fine points that leave customers' systems broken and worthless. Let me know what you are objecting to specifically: the truth of the matter, or the tone I take. I can and do apologize, and I am able to learn, grow, and change. austin@xilinx.com Austin PS: from the raw message, I can not see exactly where (or who) you are. I respect that, as I too am inundated with spam, and I understand you wishing to avoid that. John_H wrote: > And this post helps the engineering community how? > > "austin" <austin@xilinx.com> wrote in message > news:cur6bv$bag1@cliff.xsj.xilinx.com... > >>Paul, >> >>I am delighted. >> >>Not only is the static Iccint current > 7.568 amperes at 100C, but the >>device is clearly doing a thermal runaway (in Excel!). >> >>How did you do that? Does the device melt down just like the >>spreadsheet? It looks as if the solution is iterative, and it keeps >>trying to converge with the formula for the Iccint being exponetial with >>T, and the T just getting hotter, and hotter ...) >> >>Sure, when the worst case static current is less than the surge, then >>there is no "surge...." >> >>Sure. So if the worst case static is 6 ameres, what is the 'surge' at >>25C? Less than 6 amperes, but still there? >> >>Smoke and mirrors, mostly smoke? >> >>You should really check your spreadsheets before posting. >> >>EP2S180, Industrial, Maximum, no air flow, no heat sink, no logic (0 >>power in the blocks), 36 C ambient (runs away, at 35 C ambient it goes >>to ~85C. Even a 1/2 degree more causes the Tj to pop to 100+. >> >>Now, I admit this is a degenerate case, and people will ususally have >>some airflow, and maybe even a heatsink. Still ~ 6 amperes just for >>static current, but at least it won't melt down. >> >>At least V4 won't thermally runaway when you turn it on. >> >>Austin >> >>Paul Leventis wrote: >> >> >>>Hi, >>> >>>Today we released our updated power specs for Stratix II. Some >>>highlights of the updates found in the Stratix II Early Power Estimator >>>V2.1 tool: >>> >>>(1) Reduced static power by up to 47%. We've measured many units from >>>across the product family, and have the data to tighten the spec >>>compared to our previous conservative/estimated values. The amount of >>>change varies from family member to family member, and is a function of >>>junction temperature and whether typical or worst-case silicon is >>>selected. >>> >>>(2) Static current on the VccPD rail now reflected (it is tiny) >>> >>>(3) There is no more in-rush Icc current. The previous current >>>reflected a result measured on early units from one family member plus >>>some excessive guard-bands. The underlying cause was rectified and all >>>Stratix II devices now exhibit a monotonic ramp for Icc and no in-rush. >>> >>>(4) We previously reported around 100 mA of static power per used MRAM >>>in the chip. This turns out to have been a measurement error and now >>>there is no added static power. >>> >>> >>>See >>> > > http://www.altera.com/corporate/news_room/releases/products/nr-powerplay.html > >>>for details on the updates and where to get the EPE. Quartus 5.0 will >>>reflect these updated specs when it is released in Q2. >>> >>> >>>Paul Leventis >>>Altera Corp. >>> > > >Article: 79139
Piotr, The use of a SSTL input buffer, with a Vref at 1/2 the slicing level (AC couple to the input with a bias to Vref) seems to work very well for our parts (Xilinx). I imagine it would work equally well in Altera's parts (with the same IO standard and Vref). The problem with a sine wave is the slow dV/dt. That will lead to jitter when there is ground bounce. So, for example, if the signal changes 100 ps in 100 mV, then with 100 mV of ground bounce, I would expect 100 ps of jitter. More bounce, more jitter. Faster dV/dt, less jitter. The more dV/dt, the more jitter with bounce. You choose how much clock source jitter you may tolerate. A separate slicer (comparator) is a better solution in most cases. Austin Piotr Wyderski wrote: > Hello, > > I have a source of extremely stable and clean clock > signal. Its frequency is about 64 MHz. I would like to > use it as the main clock for a Cyclone FPGA chip > (1C6, to be exact). The problem is that the signal > is a sine wave with the amplitude of about 1Vpp. > The exact level is not an issue, I can amplify or attenuate > it appropriately, but the shape bothers me: may I feed > the FPGA clock input with this signal directly? If yes, > then what is the optimal level of the signal? But if this, > unfortunately, is not allowed, then what solution would > you recommend me? > > Best regards > Piotr Wyderski >Article: 79140
Brian Davis wrote:
> Hmm, Google-Groups-Beta seems to have mangled the four lines of
> code in my last post unless you use "show options" to display the
> original message.
>
> Anyone out there know how to post/read from Groups-Beta without
> it auto-mangling code & message text?
I have had similar problems and switched to this server:
http://news.individual.net/register.html
It's a real news server
and works good for free.
-- Mike Treseler
Article: 79141Hi you Rottweilers, back into your cages! We have not even started our presentation. and Paul is already playing umpire. We based our evaluations not only on those published numbers that Altera can change at will, if they are prepared to back them up, and to guarantee them. It is, however, just a little strange that their leakage current evaporated the very moment Xilinx announced a seminar about it. Cause and effect ? Marketing jitters? We also did made extensive real physical measurements, which we will report. And they cannot be prettied up by a press release. But why don't you all relax and listen what we have to say. There is plenty of space in this newsgroup for a rebuttal, and a re-rebuttal and a re-re-rebuttal. But remember, hot air just makes the current go up. If all this really produces low-static-power 90 nm devices, users should be happy. Peter Alfke, XilinxArticle: 79142
These posts, between Altera and Xilinx, help the engineering community by exposing and discussing critical design-related concerns. People (like me) dig around for any potential problems with parts -- especially the brand new ones (which we always need to use). Although we work very closely with Xilinx on the application of their latest parts, they are not always able and/or willing to disclose *all* of the known issues. Any hint of a potential problem can then be laid out on the table. They are, then, forced to address the issue. Something that may seem benign, to them, may adversely affect our designs. Having these folks jaw at each other, here, is money in the bank, for us. Bob "John_H" <johnhandwork@mail.com> wrote in message news:8TaQd.3$rp4.170@news-west.eli.net... > And this post helps the engineering community how? > > "austin" <austin@xilinx.com> wrote in message > news:cur6bv$bag1@cliff.xsj.xilinx.com... > > Paul, > > > > I am delighted. > > > > Not only is the static Iccint current > 7.568 amperes at 100C, but the > > device is clearly doing a thermal runaway (in Excel!). > > > > How did you do that? Does the device melt down just like the > > spreadsheet? It looks as if the solution is iterative, and it keeps > > trying to converge with the formula for the Iccint being exponetial with > > T, and the T just getting hotter, and hotter ...) > > > > Sure, when the worst case static current is less than the surge, then > > there is no "surge...." > > > > Sure. So if the worst case static is 6 ameres, what is the 'surge' at > > 25C? Less than 6 amperes, but still there? > > > > Smoke and mirrors, mostly smoke? > > > > You should really check your spreadsheets before posting. > > > > EP2S180, Industrial, Maximum, no air flow, no heat sink, no logic (0 > > power in the blocks), 36 C ambient (runs away, at 35 C ambient it goes > > to ~85C. Even a 1/2 degree more causes the Tj to pop to 100+. > > > > Now, I admit this is a degenerate case, and people will ususally have > > some airflow, and maybe even a heatsink. Still ~ 6 amperes just for > > static current, but at least it won't melt down. > > > > At least V4 won't thermally runaway when you turn it on. > > > > Austin > > > > Paul Leventis wrote: > > > > > Hi, > > > > > > Today we released our updated power specs for Stratix II. Some > > > highlights of the updates found in the Stratix II Early Power Estimator > > > V2.1 tool: > > > > > > (1) Reduced static power by up to 47%. We've measured many units from > > > across the product family, and have the data to tighten the spec > > > compared to our previous conservative/estimated values. The amount of > > > change varies from family member to family member, and is a function of > > > junction temperature and whether typical or worst-case silicon is > > > selected. > > > > > > (2) Static current on the VccPD rail now reflected (it is tiny) > > > > > > (3) There is no more in-rush Icc current. The previous current > > > reflected a result measured on early units from one family member plus > > > some excessive guard-bands. The underlying cause was rectified and all > > > Stratix II devices now exhibit a monotonic ramp for Icc and no in-rush. > > > > > > (4) We previously reported around 100 mA of static power per used MRAM > > > in the chip. This turns out to have been a measurement error and now > > > there is no added static power. > > > > > > > > > See > > > > http://www.altera.com/corporate/news_room/releases/products/nr-powerplay.htm l > > > for details on the updates and where to get the EPE. Quartus 5.0 will > > > reflect these updated specs when it is released in Q2. > > > > > > > > > Paul Leventis > > > Altera Corp. > > > > >Article: 79143
Bertram has the right idea. But, if you don't like to use an XOR as a clock source, you can make it an XNOR driving the D input of a flip-flop clocked by clk*2, and use that Q as the clk output. Peter AlfkeArticle: 79144
"Pablo Bleyer Kocik" <pablobleyer@hotmail.com> skrev i meddelandet news:1108427617.762469.128840@g14g2000cwa.googlegroups.com... > Martin Schoeberl wrote: > > I would be happy to go the KISS path, but I don't know how one can keep > > a soft-cpu module simple to handle. You have too many options: You're > > developing on two levels: the CPU inside the FPGA with peripheral components > > and software for the CPU. During development on one of these areas different > > ways for downloading the configuration/software fits best: > > The AT76C712/3 is a small AVR CPU with USB that boots from a (AT45DBxxx) serial (SPI) dataflash memory The dataflash can also contain the configuration data. If you let the device run the USB Mass Storage Adapter device class then the programming can be as simple as a drag and drop to the file system. You can probably setup your development environment to save the bitstream to the new "USB key" The onboard AVR runs 48 MHz so your configuration should be quite fast. Typically dataflash is much cheaper than configuration memories and you can get them in sizes up to 64 Mbit today. In SO-8 pinout, they are up to 16 Mbit today, but the 128 Mbit in SO-8 is around the corner. During configuration, the AVR can read a script file from teh FAT file system and can react accordingly maybe also taking some DIP switches in account. (You could have several configurations, very easily) After configuration, the AVR could switch to a USB<->Serial adapter. (Disabling the USB Mass Storage, until a key is pressed) -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic ABArticle: 79145
Martin Schoeberl wrote: >>>Another idea: What do you guys think about adding a slot for a SD Card [1]. >>>They are cheap (about EUR 10,- for 128MB) and you get them up to 1GB! >>>However, the impact on the board is high: The connector is 'big' and >>>increases the board hight. A FPGA with a higher pin-count is needed. For >>>the solution without the SD Card a 100pin TQFP would fit, but now a 144pin >>>is needed - again a larger board. >>>And this adds again a few EUR/$. All these design decissions! You start with >>>a minimal core design and than start adding (unnecesssary) features again. >>> >>>BTW: Has somebody inplemented an SD Card interface in an FPGA. It should >>>not be too hard [2]. The simplest solution would be the SPI bus. >> >> You might want to consider two variants: one that is on the KISS path, >>and is on the lower price knee, and just sufficent to operate a workable >>JOP, and another that is more maximal, and more able to launch an >>operating system as well. > > > I would be happy to go the KISS path, but I don't know how one can keep > a soft-cpu module simple to handle. You have too many options: You're > developing on two levels: the CPU inside the FPGA with peripheral components > and software for the CPU. During development on one of these areas different > ways for downloading the configuration/software fits best: > > Simplest: Flash is configured with JOP waiting for a download of a Java program. > How do you donwload it? Via a serial interface - Then we need a serial interface. > Program the serial Flash with the Java program. Not very comfortable during > development - You have to use Quartus for the Flash programming, but you are > only interested in Java development. > Now you start changing JOP, e.g. do some FPGA development. Do you want to > program the Flash for every try or do you prefere to download the configuration > direct to the FPGA. Then we need a second ByteBlaster adapter (one for the Flash > and one for the Cyclone). Two pin heads need space and make it more complicate > to handle the board (not the KISS path). It depends on the bandwidths, but I like Pablo's idea of a FT2232C - there may be enough smarts between that device, and your FPGA, to improve PC-target bandwidths for debug (single step?) and download -> SDRAM, prior to code FLASH for final pass. Perhaps a 'virtual jumper' in the FPGA code, or'd with a FT2232C pin, could select Load from USB.FIFO, or top of SerialConfig ? Another device that appeals for Soft-cpu is this one : http://www.st.com/stonline/press/news/year2005/p1563m.htm with 75MHz burst, 32 bits wide, that's 2400MB/s, vs 25-50MB/s on a SD card. So the SD card looses on speed, but gains on universal supply/size, and you CAN easily remove it - hmmm... perhaps put the M58BW032 on the other side of the PCB ? Maybe option the SD socket, and M58BW032, on the more complex model ? Next, some form of Codec would be nice, what about something from this selection ? http://para.maxim-ic.com/compare_noj.asp?Fam=CODEC&Tree=Wireless&HP=Wireless.cfm&ln= $5-7 for 22-60Msps ADC & DAC ? This ties in well with a SD socket, & USB link... > > Any ideas are highly welcome ;-) > > >> For package, I'd vote against pin-modules, as they are expensive >>to make, have a pin count ceiling, and are easily damaged. The only >>benefit is they can save a little time in first deployment. >> Better are the memory-card formats, as they have low cost and sturdy >>connections, that can still be socket managed on 1 & 2 layer PCB, and >>you can offer a socket-pcb for users starting from nothing. >> > > > First ideas about the memory card format (still SIMM): > http://www.jopdesign.com/jopstick/index.jsp > > One format is very small with a FPGA in TQFP100. There are just enough pins > for the SDRAM and the SimmStick bus. The second variant is larger with > a TQFP144 FPGA and a slot for a SD card. SD starts to look nice on this basis... >> Besides the simmmstick itself, you should consider the SODIMM modules, >>as seen in TINI : >> http://www.maxim-ic.com/products/tini/pdfs/TINI_GUIDE.pdf > > > Yes, another option. However, is there a kind of 'standard' for this larger modules. > Are there peripheral modules available for this form factor? The TINI itself ? ;) - plus as TINI also has Java path, you could get some cross-polination ? > >> For "smart expansion", SD would be one option, but smaller and >>more flexible might be USB-Drive ?. Not as cheap at the lowest node, >>but universally portable - few PCs can R/W SD cards, but they can all >>R/W a USB drive. >> Of course, that means the FPGA needs to be smarter :) > > > Do you mean USB host? That's not so earsy. I would expect that the FPGA > (and the software) has to be too smart ;-) You are probably right, but you did ask for suggestions :) > > Martin > > PS.: Thanks for all suggestions from the usenet group! It's really fun to discuss several > options during development of a board. -jgArticle: 79146
Paul Leventis wrote: >>We have finished our PPT slides and polished the presentation. It > will be tutorial and technical in nature, but will also not shy away from >>competitive issues. > > > Too bad the slides are done given that we've released updated power > specs. I'm sure you will carefully caveat the comparison > appropriately... If you mean these numbers, from 31 Jan, : http://www.altera.com/corporate/news_room/releases/products/nr-perf_power.html then I am sure Peter, et al, will have included those, in their PPT slides. This is a Feb 2005 comparison, after all ? If you mean this one, from 14 Feb http://www.altera.com/corporate/news_room/releases/products/nr-powerplay.html that's a harder call. Are these actually the SAME numbers, (press released twice) or has two weeks resulted in another improvement ?. They don't quite overlay, as the Jan spec says 45%, but the Feb one is 47%, or is that 'really the same number' to marketing ? -jgArticle: 79147
welcome aboard! I had with some EDK version a special void dummy_bullshit() { // some dummy code
}
in order to get my software to work I had to insert calls to dummy_bullshit();
in some places!
I still have some working sw with this bullshit fix :)
your problem seems similar!
try changing compiler options
antti
Article: 79148
Hi Philipp,
Can you disassembler the section by using "mb-objdump -S" and send me the result?
Since you are doing a blocking write on the FSL, MicroBlaze will stop if the
FIFO is full.
How fast can your FSL core consume data?
Göran
Philipp wrote:
> Hello
>
> I am really a little bit helpless at the moment. I have implemented an own
> IP which performs some special arithmetic instruction (multiplication,
> addition, root, substraktion and so on). I tested each module with thousands
> of testcases so we can be sure that thet are working properly.
> Next I added this IP to the microblaze core with the FSL interface. I
> downloaded then the complete design on my ML300 board. I run an algorithm on
> my Microblaze core which calls my instructions 8000 times and at the end of
> the day I got the correct result. So I was sure that this design is
> "perfect". But now I added 400 more instructions for an inversion
> operations, and after 50 instruction something weird is happening:
>
> If I use the following codefragment I get an incorrect result:
> ....
> command(OP_MUL, REG14, REG14, REG17);
> command(OP_MUL, REG12, REG13, REG18);
> command(OP_MUL, REG13, REG14, REG19);
> command(OP_MUL, REG12, REG14, REG20);
> command(OP_ADD, REG18, REG17, REG21);
> ....
>
>
> But if I insert a print statement within this fragement to read out one of
> my registers then it works:
> ....
> command(OP_MUL, REG14, REG14, REG17);
> command(OP_MUL, REG12, REG13, REG18);
> command(OP_MUL, REG13, REG14, REG19);
> command(OP_MUL, REG12, REG14, REG20);
> print("-- Value of REG20 --... \n\r");
> command(OP_RD, REG20, 0, 0);
>
> for (i=0;i<7;i++){
> microblaze_bread_datafsl(data_back_local_link[i],0);
> printf("Value :%u \n\r",data_back_local_link[i]);
> };
> command(OP_ADD, REG18, REG17, REG21);
> ...
>
> This really doesnt make sense! Without the print statement the value of
> REG20 is overwritten by the next instructions. If I insert the print
> statement I get the correct result. So has here anybody an idea whats going
> on? Because I executed 8000 instructions without any problems! This thing
> occured after 50 additional instrucion calls. My command is definied as
> follows:
>
> void command(opcode, op1, op2, op3) {
> int com;
> com = opcode * 16777216 + op1 * 65536 + op2 * 256 + op3;
> microblaze_bwrite_datafsl(com,0);
> }
>
> I use EDK 6.2 for design and synthesising my core. Is it perhaps possible
> that the FIFO of my Micrblaze gets full, and ignores some of the
> instructions? If yes, is there a way to prevent this?
>
> I hope that some of you guys understand my problem and could give me a hint!
>
> Thanks a lot
> Philipp
>
>
> .
>
>
Article: 79149>> Any ideas are highly welcome ;-) > > Yes. Indeed at my company we have a design that uses an FTDI FT2232C > USB controller to: > > 1- Power the board (up to 500mA@5V but you can also use external > power). > 2- Implement a JTAG interface. > 3- Implement a serial/FIFO communication line. > > You get all these from a single cable and that is very useful for > development. The FT2232C (http://www.ftdichip.com/Products/FT2232C.htm) > implements two versatile IO ports and supports a smart bit-bang mode > (MPSSE), so you can do serial or FIFO communications with one channel > and JTAG programming or debugging with the other in parallel (you even > get some GPIOs that are very handy if you need to configure your board > on the fly). We use those 'mini' type-B USB connector that save a lot > of space, and you can buy the cables cheap from Palm or mobile phone > accessory suppliers. Yes, this chip is fine. You can get rid of these download cables. So the idea is to use this USB chip to program the serial flash (in the same way as you do it with the ByteBlaster - holding the FPGA on reset with nConfig low). Or if you want to config it direct you could use the the JTAG interface - doning JTAG with the FT2232C. However, for both modes you have to provide a 'special' program and can't use Quartus anymore. Another point: I see this module as an Java SBC and not a slave of a PC. So I did understand Jim's suggestion to build an USB host. That means you can use the USB to attach flash or anything else to the SBC and not the board as USB slave to the PC. This direction was what I meant not so easy. > > Since you are fond of Java, you might enjoy the Java bindings for the > FTDI direct driver at http://jd2xx.dev.java.net/ which I maintain. I > have personally implemented an MPSSE JTAG controller using it (tested > with Xilinx FPGAs), it is not very difficult. You did configura the Xilinx FPGA in JTAG mode? That's very interesting. I hope there is enough documentation about the Altera Cyclone to do the same. >> PS.: Thanks for all suggestions from the usenet group! It's really > fun to discuss several >> options during development of a board. > > Ain't that GREAT (TM)? At least if you finally mess up you can blame > or share the guilt with others :) You mean mess up with the board or with the sales numbers ;-) > > Luck with you project. > Thanks! Martin ---------------------------------------------- JOP - a Java Processor core for FPGAs: http://www.jopdesign.com/
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