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
Mike Treseler wrote: > Eli Bendersky wrote: > > > I also try to avoid variables for another reason (in addition to the > > ones you stated). Somehow, when variables are used I can't be 100% sure > > if the resulting code is synthesizable, because it can turn out not to > > be. > > If you mean that a variable does not always infer a register I agree. > If you mean that synthesis does not always produce a netlist that > simulates the same as the code, I disagree. > Is all code using variables always synthesizable, and can you tell by a single look how many clock cycles the update of all values take ? I'd really appreciate a simple example or two. Thanks in advanceArticle: 107476
Hi David,
Please specify the connections for clock and reset ports of FSL
-Felix
"David" <simianfever@gmail.com> wrote in message
news:1156805466.190102.161630@p79g2000cwp.googlegroups.com...
Göran Bilski wrote:
> David wrote:
> > Hi all,
> >
> > I'm trying to implement a correlator as a coprocessor on the FSL bus.
> > The first thing I've done is generate the FSL example using the create
> > peripheral wizard in EDK 8.1 and hooked it up to the MicroBlaze. When
> > I do a blocking write or read the MB stalls - my understanding is that
> > this will happen if the FSL FIFO is full or empty respectively, but it
> > happens the first time I write to it, so the FIFO should not be full.
> >
> > If I use non-blocking reads and writes and check the error and invalid
> > flags after each one using fsl_isinvalid() and fsl_iserror() - see code
> > below - everything seems normal but the output is always zero. Am I
> > implementing the error checking macros correctly?
> >
> >
> > #define write_into_fsl(val, id) nputfsl(val, id)
> > #define read_from_fsl(val, id) ngetfsl(val, id)
> >
> > #define WRITE_FSL_TEST_0(val) write_into_fsl(val,
> > XPAR_FSL_FSL_TEST_0_INPUT_SLOT_ID)
> > #define READ_FSL_TEST_0(val) read_from_fsl(val,
> > XPAR_FSL_FSL_TEST_0_OUTPUT_SLOT_ID)
> >
> >
> > void fsl_test_app(
> > unsigned int* input_0, /* Array size = 2 */
> > unsigned int* output_0 /* Array size = 2 */
> > )
> > {
> > int i;
> > Xuint8 is_error = 0;
> > Xuint8 is_valid = 0;
> >
> > print("Entering fsl_test_app \r\n");
> >
> > //Start writing into the FSL bus
> > for (i=0; i<2; i++)
> > {
> >
> > WRITE_FSL_TEST_0(input_0[i]);
> > fsl_iserror(is_error);
> > xil_printf("error post: %d \r\n", is_error);
> > fsl_isinvalid(is_valid);
> > xil_printf("valid post: %d \r\n", is_valid);
> > }
> > print("Finished Write \r\n");
> >
> > is_error = 0;
> > is_valid = 0;
> >
> > //Start reading from the FSL bus
> > for (i=0; i<2; i++)
> > {
> > READ_FSL_TEST_0(output_0[i]);
> > fsl_iserror(is_error);
> > xil_printf("error post: %d \r\n", is_error);
> > fsl_isinvalid(is_valid);
> > xil_printf("valid post: %d \r\n", is_valid);
> > }
> > }
> >
> > I added external ports to the FSL core to check the reset polarity and
> > monitor the state machine - the core is not being held at reset, but
> > always sits in the Idle state. This, coupled with the blocking
> > instruction problems seems to indicate an issue with the FSL FIFO
> > perhaps (I have tried both BRAM and non-BRAM FIFO implementations)?
> > If anyone has any ideas on what might be going wrong your help would be
> > much appreciated...
> >
> >
> > Cheers,
> >
> > David
> >
> Hi,
>
> Can you show the .mhs where you have connected your FSL core with
> Microblaze?
>
> Göran Bilski
Hi Göran,
Thanks for your reply, here are the relevant parts of the .mhs file:
BEGIN microblaze
PARAMETER INSTANCE = microblaze_0
PARAMETER HW_VER = 4.00.a
PARAMETER C_USE_FPU = 0
PARAMETER C_DEBUG_ENABLED = 1
PARAMETER C_NUMBER_OF_PC_BRK = 2
PARAMETER C_FSL_LINKS = 1
BUS_INTERFACE DLMB = dlmb
BUS_INTERFACE ILMB = ilmb
BUS_INTERFACE DOPB = mb_opb
BUS_INTERFACE IOPB = mb_opb
BUS_INTERFACE SFSL0 = fsl_v20_0
BUS_INTERFACE MFSL0 = fsl_v20_1
PORT CLK = sys_clk_s
PORT DBG_CAPTURE = DBG_CAPTURE_s
PORT DBG_CLK = DBG_CLK_s
PORT DBG_REG_EN = DBG_REG_EN_s
PORT DBG_TDI = DBG_TDI_s
PORT DBG_TDO = DBG_TDO_s
PORT DBG_UPDATE = DBG_UPDATE_s
END
BEGIN fsl_v20
PARAMETER INSTANCE = fsl_v20_0
PARAMETER HW_VER = 2.00.a
PARAMETER C_EXT_RESET_HIGH = 0
PARAMETER C_IMPL_STYLE = 1
END
BEGIN fsl_v20
PARAMETER INSTANCE = fsl_v20_1
PARAMETER HW_VER = 2.00.a
PARAMETER C_EXT_RESET_HIGH = 0
PARAMETER C_IMPL_STYLE = 1
END
BEGIN fsl_test
PARAMETER INSTANCE = fsl_test_0
PARAMETER HW_VER = 1.00.c
BUS_INTERFACE MFSL = fsl_v20_0
BUS_INTERFACE SFSL = fsl_v20_1
PORT reset_out = fsl_test_0_reset_out
PORT state_debug = fsl_test_0_state_debug
END
Cheers,
David
Article: 107477Thanks! I stand corrected. In the paper there are several arbiter implementations with varying request, grant protocols. I was assuming the simples protocol being used: Figure 1 and 2, 3 (also valid for Fig 6 logic) So the answer is in fact yes (req and grant exactly one cycle) for protocols used in cases shown on Figures 7-9 (answer is no for Fig 1-6) Cheers, Przemek Doug MacKay wrote: > bazarnik@hotmail.com wrote: > > <snip> > > > > Obviously request will be active for several clock cycles. > > This is beacuse some waiting time for acknowledge is necessary. > > (If not then why would we need arbiter?) > > > > <snip> > > > > Cheers, > > Przemek > > Not so obvious. Some arbiters contain logic to queue incoming requests > and (for example) will interpret 4 continuous cycles of request > assertion as 4 separate requests. > > This can be useful if your arbitration logic requires multiple cycles > while being expected to handle a new request every cycle.Article: 107478
David wrote:
> Göran Bilski wrote:
>
>
>>David wrote:
>>
>>>Hi all,
>>>
>>>I'm trying to implement a correlator as a coprocessor on the FSL bus.
>>>The first thing I've done is generate the FSL example using the create
>>>peripheral wizard in EDK 8.1 and hooked it up to the MicroBlaze. When
>>>I do a blocking write or read the MB stalls - my understanding is that
>>>this will happen if the FSL FIFO is full or empty respectively, but it
>>>happens the first time I write to it, so the FIFO should not be full.
>>>
>>>If I use non-blocking reads and writes and check the error and invalid
>>>flags after each one using fsl_isinvalid() and fsl_iserror() - see code
>>>below - everything seems normal but the output is always zero. Am I
>>>implementing the error checking macros correctly?
>>>
>>>
>>>#define write_into_fsl(val, id) nputfsl(val, id)
>>>#define read_from_fsl(val, id) ngetfsl(val, id)
>>>
>>>#define WRITE_FSL_TEST_0(val) write_into_fsl(val,
>>>XPAR_FSL_FSL_TEST_0_INPUT_SLOT_ID)
>>>#define READ_FSL_TEST_0(val) read_from_fsl(val,
>>>XPAR_FSL_FSL_TEST_0_OUTPUT_SLOT_ID)
>>>
>>>
>>>void fsl_test_app(
>>> unsigned int* input_0, /* Array size = 2 */
>>> unsigned int* output_0 /* Array size = 2 */
>>> )
>>>{
>>> int i;
>>> Xuint8 is_error = 0;
>>> Xuint8 is_valid = 0;
>>>
>>> print("Entering fsl_test_app \r\n");
>>>
>>> //Start writing into the FSL bus
>>> for (i=0; i<2; i++)
>>> {
>>>
>>> WRITE_FSL_TEST_0(input_0[i]);
>>> fsl_iserror(is_error);
>>> xil_printf("error post: %d \r\n", is_error);
>>> fsl_isinvalid(is_valid);
>>> xil_printf("valid post: %d \r\n", is_valid);
>>> }
>>> print("Finished Write \r\n");
>>>
>>> is_error = 0;
>>> is_valid = 0;
>>>
>>> //Start reading from the FSL bus
>>> for (i=0; i<2; i++)
>>> {
>>> READ_FSL_TEST_0(output_0[i]);
>>> fsl_iserror(is_error);
>>> xil_printf("error post: %d \r\n", is_error);
>>> fsl_isinvalid(is_valid);
>>> xil_printf("valid post: %d \r\n", is_valid);
>>> }
>>>}
>>>
>>>I added external ports to the FSL core to check the reset polarity and
>>>monitor the state machine - the core is not being held at reset, but
>>>always sits in the Idle state. This, coupled with the blocking
>>>instruction problems seems to indicate an issue with the FSL FIFO
>>>perhaps (I have tried both BRAM and non-BRAM FIFO implementations)?
>>>If anyone has any ideas on what might be going wrong your help would be
>>>much appreciated...
>>>
>>>
>>>Cheers,
>>>
>>>David
>>>
>>
>>Hi,
>>
>>Can you show the .mhs where you have connected your FSL core with
>>Microblaze?
>>
>>Göran Bilski
>
>
>
> Hi Göran,
>
> Thanks for your reply, here are the relevant parts of the .mhs file:
>
> BEGIN microblaze
> PARAMETER INSTANCE = microblaze_0
> PARAMETER HW_VER = 4.00.a
> PARAMETER C_USE_FPU = 0
> PARAMETER C_DEBUG_ENABLED = 1
> PARAMETER C_NUMBER_OF_PC_BRK = 2
> PARAMETER C_FSL_LINKS = 1
> BUS_INTERFACE DLMB = dlmb
> BUS_INTERFACE ILMB = ilmb
> BUS_INTERFACE DOPB = mb_opb
> BUS_INTERFACE IOPB = mb_opb
> BUS_INTERFACE SFSL0 = fsl_v20_0
> BUS_INTERFACE MFSL0 = fsl_v20_1
> PORT CLK = sys_clk_s
> PORT DBG_CAPTURE = DBG_CAPTURE_s
> PORT DBG_CLK = DBG_CLK_s
> PORT DBG_REG_EN = DBG_REG_EN_s
> PORT DBG_TDI = DBG_TDI_s
> PORT DBG_TDO = DBG_TDO_s
> PORT DBG_UPDATE = DBG_UPDATE_s
> END
>
>
> BEGIN fsl_v20
> PARAMETER INSTANCE = fsl_v20_0
> PARAMETER HW_VER = 2.00.a
> PARAMETER C_EXT_RESET_HIGH = 0
> PARAMETER C_IMPL_STYLE = 1
> END
>
> BEGIN fsl_v20
> PARAMETER INSTANCE = fsl_v20_1
> PARAMETER HW_VER = 2.00.a
> PARAMETER C_EXT_RESET_HIGH = 0
> PARAMETER C_IMPL_STYLE = 1
> END
>
> BEGIN fsl_test
> PARAMETER INSTANCE = fsl_test_0
> PARAMETER HW_VER = 1.00.c
> BUS_INTERFACE MFSL = fsl_v20_0
> BUS_INTERFACE SFSL = fsl_v20_1
> PORT reset_out = fsl_test_0_reset_out
> PORT state_debug = fsl_test_0_state_debug
> END
>
> Cheers,
>
> David
>
Hi,
You need to connect the system clock to the fsl_v20 modules.
They are non clocked right now.
One good trick is always to look at the top level vhdl file in the hdl
directory. It's called system.vhd
In that file you will see what signals are connected to what and it this
case you should be able to see that the fsl bus doesn't have any clock
connected.
Göran Bilski
Article: 107479Uwe Bonnes wrote: > Antti <Antti.Lukats@xilant.com> wrote: > ... >> > >> > Related to this subject: >> > >> > Did anybody see a XC3S500E-PQ208 out in the wild? >> > > >> Sure! I have a board with that chip on. It was the first S3e board >> being shipped at all ASFAIK (looong time before s3esk !), its the s3e >> usb module from cesys GmbH > > Neither the "Xilinx" Online store nor digikey list that part... in the US, I was able to purchase these parts from NewHorizonsArticle: 107480
Remis Norvilis wrote: > Uwe Bonnes wrote: > >> Antti <Antti.Lukats@xilant.com> wrote: >> ... >>> > >>> > Related to this subject: >>> > >>> > Did anybody see a XC3S500E-PQ208 out in the wild? >>> > >> >>> Sure! I have a board with that chip on. It was the first S3e board >>> being shipped at all ASFAIK (looong time before s3esk !), its the s3e >>> usb module from cesys GmbH >> >> Neither the "Xilinx" Online store nor digikey list that part... > > > in the US, I was able to purchase these parts from NewHorizons Sorry for mistyping ;), I meant NuHorizonsArticle: 107481
David Ashley <dash@nowhere.net.dont.email.me> writes: > > One of the Neal Stephenson books, or more than one, makes an > interesting point about the concept of metaphores. Or it could > be an Eric S Raymond essay like at first there was the command line... > Right both times, sort of :-) Neal Stephenson wrote "in the beginning was the command line" http://www.cryptonomicon.com/beginning.html Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 107482
fpga_toys@yahoo.com writes: > David Ashley wrote: > > The parallel as previously mentioned by others between ASM and > > HLL development seems to match exactly with VHDL/Verilog and > > ...what? Something that may not exist yet but ought to. Maybe it's > > FpgaC. > > > > So is there a web site for this or something? > > http://sourceforge.net/projects/fpgac > Can I suggest you stick the docs up on the actualy web somewhere, last time I looked, they were all in SVN. I checked them out and there was some very interesting stuff in there, but I imagine most people would like to have a read of what you have more easily than that... > See what's checked into SVN ... it's a bit more current. Fixes, help, > comments always welcome. There are several of us doing development > around time demands for work, families, etc ... but I mostly carry it. > I have several major changes, including a new symbolic boolean solver > in my personal development tree that will be checked soon. The LUT-4 > based truth table design is fast, but produces relatively poor > technology mappings .... and doesn't scale with the 2^N nature of truth > tables, and the QM sum of products back end. > Are you going to start making use of the carry chain... last time I tried a counter, it didn't go anywhere near it, just a big lump of LUT4s - took me right back to uni, doing next-state logic minimisations for a counter! Have you considered doing a higher-level technology independent VHDL/Verilog backend, which could then be thrown into a normal synthesizer and let it ifugre out the best adders and such like - they've been practising that for a number of years now :-) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 107483
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message news:44f1d74f$0$12642$3b214f66@tunews.univie.ac.at... >>> BTW: As I'm also academic I should/have to publish papers. SimpCon >>> is on my list for months to be published - and now it seems to be >>> the right time. I will write a draft of the paper in the next few >>> days. If you are interested I'll post a link to it in this thread >>> and your comments are very welcome. >>> >> OK. >> > I've uploaded the first draft of the paper: > http://www.jopdesign.com/doc/simpcon_date.pdf > > It's still very similar to the SimpCon definition > at opencores.org. Comments are very welcome. Mostly minor comments Section 1.1.1 Avalon After the question "How is the great complexity handled?" You answered with "The switch fabric is in charge to connect those different devices and perform the necessary conversion" This is generally not quite the case. It is up to the Avalon slave design to perform the necessary conversions (I believe this is referring to whether this is a 'simple' connection or a pipeline with variable latency) with the Avalon fabric responsible for the connections between the devices (as you said). I think the SOPC Builder tool and the various components that Altera bundles in with SOPC Builder is giving the impression that it is the fabric but my interpretation is that SOPC Builder is allowing you to easily create slave components that can be used to interface to external parts without even writing a single line of VHDL as you at first did. That leads to the last question of "Who provides this switch fabric? Is it proprietary Altera design, or are there open source implementations available?" The switch fabric itself can easily be written, it is on the order of six lines of code per interface for a point to point connection, there is nothing really magic in what Altera spits out of SOPC Builder based on the Avalon bus definition. I don't think it would be difficult to create an open source version of this connection logic, but whether simple use of the Avalon bus without also targetting an Altera device (even if no Altera software is involved) is violating anything is an open legal question as you've pointed out (I'm guessing that it might but not really sure). Section 2 In the paragraph starting "The third issue is..." you ask the question "Why not force the slaves to hold the data on the output registers as long as there is no new transaction?" A couple follow up questions to that though would be - What is a SimpCon slave to do if there IS a new transaction before the old one has been acknowledged? - Does the SimpCon fabric prevent this from happening? (I think it does, but not exactly sure) Other comments: Personally, I'm still a bit confused about just exactly which pipeline on the master side is 'released' when rdy_cnt hits the magic number and how that differs from releasing the Avalon master address/command pipeline via waitrequest and releasing the Avalon master readdata pipeline via readdatavalid. With the JOP example we've been bandying about I accept that it's not totally the master address/command that is being released but 'something' on the JOP master for kick starting the data processing pipeline based on the read data actually becoming available (and getting 'early' notice of this). Maybe my last post regarding the use of the Avalon waitrequest signal to generate the SimpCon early rdy_cnt signal came too late to make it to the presses, but I think that addresses the perceived Avalon issue. Although now that I think I understand how rdy_cnt works and where it really comes from it might seem again that since my Avalon master side change involved having the master 'know' the latency about the 'slave' would seem to be cheating (since this wasn't required by the SimpCon implementation as I had thought) but I guess I'll fall back to what Tommy mentioned earlier that since JOP was optomized for SimpCon in the first place it implies that an Avalon/SimpCon bridge must be built and such bridges can tend to be either less than optimal in performance (as your performance numbers indicate) or involve a bit of cheating to get maximum performance (as my change would be). Had JOP been optomized for Avalon to begin with would the numbers be any better without any cheating? That's sort of the open question and I'm not necessarily expecting an answer. My main interest in the thread was in understanding what sort of bottlenecks might be lurking in Avalon that I'm not aware of. A couple areas of 'possible' weakness for Avalon that I am aware of are: - It can hang (there is no requirement for a max time for a cycle). Something to be aware of, but generally not an issue since whoever is designing the slave components had better address this and not allow for a hang to occur. - No notion of a 'retry'. Again, given the environment of being on a chip, the slave design shouldn't be allowe to say 'try again later please' so I don't think this should be an actual design issue, just something to be aware of. - Can't have pending reads from multiple slaves. I suppose this could be important to some, it hasn't for me. Another possible area of weakness 'might' be whatever it is that is hindering performance of JOP on Avalon as compared to JOP on SimpCon. If fundamentally it's just the SimpCon/Avalon bridge and that a native JOP on Avalon would not require any cheating and would meet performance then there is no other issue then. Just curious, Figure 7 shows pipelined reads from a static RAM where a new address is presented on every other clock cycle which matches the performance of the actual SRAM. If the device had been an external DRAM/DDR or such, you can clock out a new read command on every clock cycle even before you get the first data item back. After the data from that first read does eventually come back, the data from the subsequent reads will also come back on consecutive clock cycles. Does SimpCon support that sort of device? Or would it have to take multiple clock cycles per read? At first glance since the slave has only the one 'rdy_cnt' it would appear that it would not whereas the mythical "native Avalon interface JOP" would be able to hit the DRAM at a much higher rate. But maybe it could by varying the rdy_cnt differently on the 'first' access as compared to subsequent accesses. Like I said, nothing major just minor things. SimpCon can be the answer to certain bus issues, Avalon, Wishbone, VSIA may be the answer to others. It's good to have choices. > To KJ and Tommy: I've added you both in the > Acknowledgments. I hope this is ok with you ;-) > Fine by me...by the way, I wouldn't consider the exchanges in the thread to be either 'heated' (as mentioned by Tommy) or 'controversial' (since I don't see what the controversy was). It was interesting and civil, the large number of back and forth that remained on topic would seem to indicate that.....'heated' and 'controversial' seems to occur when mention of 'asynchronous resets' or 'coding style of state machines' is the topic. KJArticle: 107484
Hi everyon, hope someone can give me a pointer or help. I lowered the system clock in the Altera stratix example design (standard) from 50 to 35 Mhz. Is it necessary to change the time shift of the sdram clock?? (-3.5ns by default) because, a time shift of -3.5 ns seems to work fine until i fixed a huge (around 10k LE) jpeg decompression unit on to the system. Does anyone know do i need a new time shift or not? I tried a several delay from -1.0 to -8ns, but the system is still not stable, my c program can be downloaded to the board but at times fails to verification. (It sometimes passes verification, but the program doesn't run properly. To simplify debugging, I only put a printf statment in my main(), but it doesn't print) ps. I put my program and all data memory in sdram ThanksArticle: 107485
fpga_toys@yahoo.com wrote: > I got the impression from somewhere, that the bga carriers that are > direct die attach also have their own power and ground planes, so that > an individual chip pwr/gnd couples to those planes, which are then > coupled in parallel to the users PCB power planes. It seems that if > this is true, and Xilinx provided both some serious bulk capacitance > and mixed high speed, that the current profiles thru the parallel vias > to the users pcb should be much calmer, and not have a lot of > harmonics. The planes would probably be a hacked up mesh at best, but > better than 4mil traces. I guess in theory the planes on the BGA could resonate with the board power planes and produce a pretty high frequency hole, but that would largely depend on the inductance of the connection and I expect you would need to measure that to see how bad it is. Mostly it is important to design low impedance, broadband power planes and then I would treat the package as inductance in the path to the chip causing ground/power bounce. Adding caps or planes to the package will not mitigate the bounce problem. > Hmmm ... that explains some experimental data, thanks!! And contrary to > this thread, why stacked cap debug configurations sometimes seem to > actually work since the 0.1uf and 1uf "bulk caps" stacked over the > 0.01uf would have a different ESR's and help damp this by flattening > the current profile in both the cap's and via's inductive response. The > 0.01uf caps high current recharge path would be the two bulk caps > instead of resonating with the pwr/gnd plane, and the 0.1uf would more > slowly reduce the current source to the via inductor, tapering off > rather than more abruptly running out of charge early, thus > smoothing/damping the via inductors resonate current response. I'm not sure your analysis is accurate, but it is a rare case where adding caps will hurt. The smallest cap will produce the highest frequency parallel resonance. Any lower frequency parallel resonance will be mitigated by the capacitive effect of the smaller cap. It is hard to analyze this stuff by thinking about it. It is much better to simulate it or to measure it. If nothing else you can check out the Ritchey book, "Right The First Time, A Practical Handbook on High Speed PCB and System Design, Volume 1". He is promising a Volume 2, "Included in this text will be a thorough treatment of EMI; a comprehensive description of the PCB fabrication process and PCB materials; a detailed examination of simulation tools and their use and a complete discussion of Gigabit and higher signaling protocols."Article: 107486
On a sunny day (29 Aug 2006 11:42:00 +0100) it happened Martin Thompson <martin.j.thompson@trw.com> wrote in <uk64rzuvb.fsf@trw.com>: >David Ashley <dash@nowhere.net.dont.email.me> writes: > >> >> One of the Neal Stephenson books, or more than one, makes an >> interesting point about the concept of metaphores. Or it could >> be an Eric S Raymond essay like at first there was the command line... >> > >Right both times, sort of :-) > >Neal Stephenson wrote "in the beginning was the command line" >http://www.cryptonomicon.com/beginning.html I have just read part of that, he really gets out there.... :-) For me, one thing the 'command line' interface does, is allow me to speak normal language to a computer. This is important in interfacing to computers with speech. For example I have a script (Linux Bash) called 'show', and a PCI satellite card in the PC. http://panteltje.com/panteltje/satellite/show When I _type_ 'show BBC2' at the command prompt, then it will steer the dish to one of the Astra satellites and start mplayer. And when I _say_ 'show bbc2' it will do the same, using perlbox voice. The ability to make commands that are simply spelled as English words is perhaps the most powerful thing. 'Random access'. You often _know_ what program or action you want the computer to do, and going via many menus to dig deeper and deeper is a barrier, takes time. I run X and fvwm with 9 xterms, 9 virtual screens. MS was dead from me when they killed DOS command line in win 95 just to get rid of DR DOS ...... Same in FPGA, use makefiles, scripts. To pester MS windows users I say sometimes: 'My PC speaks English'.Article: 107487
Austin Lesea wrote: > Rick, > > Via in pad (basically no trace) is best. Placement is not critical, as > long as you have via in pad, and planes. > My memory is fuzzy on this (and other topics for that matter) but I think via in pad creates an assembly issue because the pad of the part is physically blocking the via (by design). Unfortunately I don't recall the specifics, maybe someone else recalls. Unless you already understand the issue (that I've conveniently forgotten) I would suggest that whoever is going to be building your boards be consulted to understand if there are appropriate tradeoffs that can be made prior to planning to use 'via in pad' since manufacturability is also generally a concern that at least must be taken into consideration and evalutated. KJArticle: 107488
Tony wrote: > Hi everyon, hope someone can give me a pointer or help. > > I lowered the system clock in the Altera stratix example design > (standard) from 50 to 35 Mhz. Is it necessary to change the time shift > of the sdram clock?? (-3.5ns by default) > > because, a time shift of -3.5 ns seems to work fine until i fixed a > huge (around 10k LE) jpeg decompression unit on to the system. Does > anyone know do i need a new time shift or not? > I tried a several delay from -1.0 to -8ns, but the system is still not > stable, my c program can be downloaded to the board but at times fails > to verification. > > (It sometimes passes verification, but the program doesn't run > properly. To simplify debugging, I only put a printf statment in my > main(), but it doesn't print) > > ps. I put my program and all data memory in sdram > Thanks When adding a huge amount of switching logic to any design, errors are very likely introduced by either placement or power supply droop. If you have any unconstrained paths, the large addition can create problems. However it is also likely that the additional power draw of the jpeg decompression is causing issues. I would recommend putting a scope on the power to make sure you're not getting a significant voltage drop due to the increased switching. Also when reducing the SDRAM clock, make sure you don't violate the refresh period requirements. Normally refresh timing is done by counting clock cycles, but the parts require refresh periods that are not clock rate dependent, so you would need to reduce the number of cycles between refreshes by the ratio of the clock rate reduction. HTH, GaborArticle: 107489
KJ wrote: > Austin Lesea wrote: >> Rick, >> >> Via in pad (basically no trace) is best. Placement is not critical, as >> long as you have via in pad, and planes. >> > My memory is fuzzy on this (and other topics for that matter) but I > think via in pad creates an assembly issue because the pad of the part > is physically blocking the via (by design). Unfortunately I don't > recall the specifics, maybe someone else recalls. > > Unless you already understand the issue (that I've conveniently > forgotten) I would suggest that whoever is going to be building your > boards be consulted to understand if there are appropriate tradeoffs > that can be made prior to planning to use 'via in pad' since > manufacturability is also generally a concern that at least must be > taken into consideration and evalutated. > > KJ Via in pad is a bad thing if you don't have filled vias since they would otherwise wick the solder away from the component. This "solder thief" can present a reliability problem beyond initial build because of trapped gasses even if the connection started out as good. Filled vias are an extra process that will cost a little money but most PC vendors can do it. The benefits in lower inductance can be great.Article: 107490
John_H wrote: > KJ wrote: > > Austin Lesea wrote: > >> Rick, > >> > >> Via in pad (basically no trace) is best. Placement is not critical, as > >> long as you have via in pad, and planes. > >> > > My memory is fuzzy on this (and other topics for that matter) but I > > think via in pad creates an assembly issue because the pad of the part > > is physically blocking the via (by design). Unfortunately I don't > > recall the specifics, maybe someone else recalls. > > > > Unless you already understand the issue (that I've conveniently > > forgotten) I would suggest that whoever is going to be building your > > boards be consulted to understand if there are appropriate tradeoffs > > that can be made prior to planning to use 'via in pad' since > > manufacturability is also generally a concern that at least must be > > taken into consideration and evalutated. > > > > KJ > > Via in pad is a bad thing if you don't have filled vias since they would > otherwise wick the solder away from the component. This "solder thief" > can present a reliability problem beyond initial build because of > trapped gasses even if the connection started out as good. > > Filled vias are an extra process that will cost a little money but most > PC vendors can do it. The benefits in lower inductance can be great. I would love to see some data to support that statement about the lower inductance. I don't have Ritchey's book handy, but I seem to recall that moving the vias from the end of the pads to the side was only a small delta in total inductance (significantly smaller loop area). I expect that moving them to the center would be another small delta. This has to be considered in the context of both the inductance of the device itself as well as the result on the impedance of the board. I think you will find that small changes in inductance do not have a major effect on the utility of the caps. If you use multiple caps with mutiple values you can get a low impedance over a wide bandwidth with a minimum number of caps. I have no doubt that using via in pad will help to raise the resonant frequencies, but I think you will find that if you do all the other things right it will not make much difference in the end.Article: 107491
"Nevo" <nevo_n@hotmail.com> wrote in message news:0NjIg.1843$XD1.927@trnddc01... > I'm designing a Cyclone device and am having problems with one pin. > > I want to use the configuration pin ASDO as an I/O pin after my device finishes active serial > configuration. I assigned my I/O to that pin but the fitter barks at me that it "Can't place node > ~ASDO~ in location 37 because location already occupied by Q[0]" > I went to Assignments... Device... Device & Pin Options... Dual-Purpose Pins, but the setting for > ASDO is greyed out. > How do I tell Quartus to let me use that pin as an I/O pin after AS configuration? It's not explicitly defined on that config page but looking at it I'd say that if you're using active serial config then ADS0 isn't later available as a user IO pin. Probably worth confirming with an Altera FAE. Nial ---------------------------------------------------------- Nial Stewart Developments Ltd Tel: +44 131 561 6291 42/2 Hardengreen Business Park Fax: +44 131 561 6327 Dalkeith, Midlothian EH22 3NU www.nialstewartdevelopments.co.ukArticle: 107492
Thomas Entner schrieb: > I got my board some weeks ago, but had no time to play with it yet... > > Thomas > > www.entner-electronics.com > > "MikeD" <mmdst23@gmail.com> schrieb im Newsbeitrag > news:1156795063.217881.84720@i42g2000cwa.googlegroups.com... > > Has anyone here had any experiance with the Actel Fusion FPGAs? I saw > > a couple of posts asking this about 6 months ago, but no one had > > hardware yet. Did they finally start shipping their demo boards? > > > > Is this true programable analog, with filtering/amplification/etc, or > > is it just an analog mux to an ADC? > > > > Thanks, > > Mike > > I got mine some months ago :) and I have PQ208 packages silicon samples as well, but havent had time to play either. The FPGA analog input demo sure works, but thats all I looked AnttiArticle: 107493
jaxato, I am not involved in that battle, as Peter is fighting it. He and I both agree that not having an on line store in this day and age is unacceptable. As soon as Peter returns from Europe, I am sure he will let us know how it is progressing (or not). Please send all your request to Peter directly (if you haven't already). Each email helps just a little bit. Austin jaxato@gmail.com wrote: > Hi Austin, > > Is it the online store that went off in May or June that you are > talking about? the same one on the Xilinx portal and straight from > Xilinx warehouse (in Singapore for example)? > Is it really going to be back online? and with Virtex-4 and 5 for sale? > Woh, if that's the truth, then you make my day!!! > Please dont forget to put discount prices for relatively big qty too > (>24) > > Cheers > Jacques > > Austin Lesea wrote: >> Brian, >> >> Peter is still tilting at that windmill (the on line store). >> >> I am cheering him on. >> >> Perhaps Peter can tell us how the on line store is progressing when he >> bets back from Europe. >> >> Austin >Article: 107494
Peter I would appreciate your help ! I have sent you an e-mail. I talked to Nu Horizons on Aug 28 and they say qty 3 of Engineering Samples of the XC5VLX50-1FF676CES are not available until May 2007. I am told by Nu Horizons only selected "big" customers can get samples. The part we are wanting to buy is not any peculiar combination of package-speed-temp range and not even a production version of the part. I don't know what the supply of Virtex 5 looks like from Xilinx's side but from the customer side of distribution the Virtex5 is not available. I am not accusing Xilinx but am letting you know what customers who want to design with the V5 are hearing. As a background our company has been a Xilinx customer since 1990 and has bought thousands of parts through the years. Peter Alfke wrote: > V5LX50 have been available for several months. > I don't want to get into a fight with your distributor, but he is > feeding you nonsense data. > Unless you want a peculiar combination of package-speed-temp range > there should be no problem getting many samples now. > If you have trouble, send me an e-mail. But I will be gone through > labor day, Sept 4. > Peter Alfke, peter@xilinx.com > ========================== > jeffnewcomb@nci-usa.com wrote: > > I questioned the availability of the Virtex5 back in July on this group > > and got some responses from Xilinx people saying it was being sampled > > and to get a sample I needed to get an order in immediately. I did that > > even though the parts were not even in distributors systems and the > > local Xilinx reps initially were not sure what delivery would be. I > > did get a response back from the rep saying there was a 13 week > > delivery for an engineering sample which would be in late Sept. and you > > could not get production parts until next year. I could live with that > > and proceeded with my design using a V5LX50. Yesterday we got a FAX > > from our distributor /rep saying delivery of the engineering sample > > would not be until May 2007!!!. This is a full year after the part was > > anounced. I have seen numerous advertisements for the Virtex 5 > > "Shipping NOW". Does anyone know the truth behind this part ???? Are > > there major problems with the part?Article: 107495
fpga_toys@yahoo.com wrote: > Antti wrote: > >>1) XUP Board is *not* made by Xilinx, neither is Xilinx claiming it can >>do SATA > > > 1) title blocks on schematics ... Xilinx authorship/ownership > 2) Reference manual ... Xilinx authorship/ownership > 3) PCB artwork ... Xilinx authorship/ownership > 4) Search RM for Digilent ... reference only compatability with > Digilent boards. > > The unit does have Digilent compatable I/O ports, and may well have > been designed under contract for Xilinx, but that does make it a Xilinx > labeled Product that they claim ownership of, no matter who is building > it for them. In fact, everything suggests it's actually a Xilinx > Research Labs design instead ... specifically using Digilent I/O > connectors for the University Program, to make it compatable with > student board projects. > > And yes, I did finally find the statement on the bottom of page 67 in > the reference manual which starts "the SATA specification requires an > out of band signalling state that is to be used when the channel is > idle. ... " > > Which means that since this is REQUIRED, and not provided the serial > interfaces are NOT SATA, but simply have the same data rates and > encoding ... not SATA which is a full system level specification. Using > SATA everywhere to describe the interface, and not meeting the > specification is simply bait and switch, substituting the Xilinx bit > serial interconnect in it's place which just happens to be a > non-compatable subset of the SATA standard. > > A parallel 16 bit data bus with control signals is not SCSI, unless it > at least is capable of operating with the complete SCSI protocol ... > anything short of that, and it's SASI, Pertec, or some other 16 bit > bus, maybe even 16 bit ISA/EISA. > fpga_toys, The reason why SATA connectors are used in the XUP board is primarily to provide inexpensive high-speed connection between boards, either between 2 boards, or a number of boards in a ring. As the SATA leads are a commodity item, they are really inexpensive compared to other high-speed leads, and easy to get hold of around the world. That said, its understandable that people see SATA and immediately think hard drives. We tried in the documentation to explain the difficulty of connecting to drives, for example, on page 67 of the user guide, we stated The SATA specification requires an out-of band signalling state that is to be used when the channel is idle. This capability is not directly provided by the MGTs. Two resistors, an FET transistor, and two AC coupling capacitors along with special idle state control signals add the out-of-band IDLE state signaling capability to the MTGs. Additional off-board hardware can be required to properly interface to generic SATA disk drives. I know this doesn't help your particular situation - you still have a very nice board, even if it doesn't work for your SATA project. Please drop me a line if you'd like to discuss this further - I'd be particularly interested in any thoughts you have on how we could have documented this better. PhilArticle: 107496
Hi all. I'm an undergrad student doing a year long project on designing an 8051 variant for FPGA. We're required to decide upon the specifications, by targeting any particular application. I'd be really thankful for any suggestions for the applications.... Could someone guide me to sites that offer a comparison, & applications of available 8051 cores? thanx in advanceArticle: 107497
Phil James-Roxby schrieb: > fpga_toys@yahoo.com wrote: > > Antti wrote: > > > >>1) XUP Board is *not* made by Xilinx, neither is Xilinx claiming it can > >>do SATA > > > > > > 1) title blocks on schematics ... Xilinx authorship/ownership > > 2) Reference manual ... Xilinx authorship/ownership > > 3) PCB artwork ... Xilinx authorship/ownership > > 4) Search RM for Digilent ... reference only compatability with > > Digilent boards. > > > > The unit does have Digilent compatable I/O ports, and may well have > > been designed under contract for Xilinx, but that does make it a Xilinx > > labeled Product that they claim ownership of, no matter who is building > > it for them. In fact, everything suggests it's actually a Xilinx > > Research Labs design instead ... specifically using Digilent I/O > > connectors for the University Program, to make it compatable with > > student board projects. > > > > And yes, I did finally find the statement on the bottom of page 67 in > > the reference manual which starts "the SATA specification requires an > > out of band signalling state that is to be used when the channel is > > idle. ... " > > > > Which means that since this is REQUIRED, and not provided the serial > > interfaces are NOT SATA, but simply have the same data rates and > > encoding ... not SATA which is a full system level specification. Using > > SATA everywhere to describe the interface, and not meeting the > > specification is simply bait and switch, substituting the Xilinx bit > > serial interconnect in it's place which just happens to be a > > non-compatable subset of the SATA standard. > > > > A parallel 16 bit data bus with control signals is not SCSI, unless it > > at least is capable of operating with the complete SCSI protocol ... > > anything short of that, and it's SASI, Pertec, or some other 16 bit > > bus, maybe even 16 bit ISA/EISA. > > > > fpga_toys, > > The reason why SATA connectors are used in the XUP board is primarily to > provide inexpensive high-speed connection between boards, either between > 2 boards, or a number of boards in a ring. As the SATA leads are a > commodity item, they are really inexpensive compared to other high-speed > leads, and easy to get hold of around the world. > > That said, its understandable that people see SATA and immediately think > hard drives. We tried in the documentation to explain the difficulty > of connecting to drives, for example, on page 67 of the user guide, we > stated > > The SATA specification requires an out-of band signalling state that is > to be used when the channel is idle. This capability is not directly > provided by the MGTs. Two resistors, an FET transistor, and two AC > coupling capacitors along with special idle state control signals add > the out-of-band IDLE state signaling capability to the MTGs. Additional > off-board hardware can be required to properly interface to generic SATA > disk drives. > > I know this doesn't help your particular situation - you still have a > very nice board, even if it doesn't work for your SATA project. Please > drop me a line if you'd like to discuss this further - I'd be > particularly interested in any thoughts you have on how we could have > documented this better. > > Phil Phil, the OOB workaround is on board. that fine, so basically it useable for SATA (if you are lucky and the drive is working in suitable for V2Pro manner) but there is NO off-board hardware available that would connect to the SATA connector of XUP board and make the XUP to fully work with any generic SATA drive. Correct me if I am wrong about this. there are many choices to make XUP board a SATA board 1) use add-on board with SATA PHY 2) use add-on board with SATA PATA bridge 3) use add-on board with PCI-SATA bridge 4) use add-on board with some other SATA bridge but none of those solutions would use the SATA connectors that are on board. sure SATA connectors are nice low cost connectors suitable for high speed transmittion, but if SATA connectors are added to any board for other intended use then SATA then this should be fully described and explained in the board documentation, what currently isnt the case. latest manuals for at least, those boards ML300 XUP V2Pro ML405 ML410 all list that SATA is operational and useable, not stating that there are severe restrictions regarding the possible use, and that there are no workarounds available. So all those documents should list something like: SATA connectors can be used for custom protocols, and for SATA experiments with the SATA products that do not use spread spectrum. additionally ML300 and XUP board documentation should read: can only work with SATA drivers when the SATA drive bit clock initial error is less than +-150ppm (SATA spec is +-300ppm) additionally ML300 documentation should read: for SATA OOB signalling external add on circuitry is required. without those additions to the manuals, some p***** off guy could get some lawer and sue Xilinx on false advertizing. I guess no one is so upset, and it would not pay off, but it would still nice to be clean as of not adertizing features that either can not be used, or can only be used with severe restrictions AnttiArticle: 107498
Eli Bendersky wrote: > Mike Treseler wrote: > > Eli Bendersky wrote: > > > > > I also try to avoid variables for another reason (in addition to the > > > ones you stated). Somehow, when variables are used I can't be 100% sure > > > if the resulting code is synthesizable, because it can turn out not to > > > be. > > > > If you mean that a variable does not always infer a register I agree. > > If you mean that synthesis does not always produce a netlist that > > simulates the same as the code, I disagree. > > > > Is all code using variables always synthesizable, and can you tell by a > single look how many clock cycles the update of all values take ? I'd > really appreciate a simple example or two. > Thanks in advance In VHDL, a variable is a more "abstract" construct. Unlike a signal, which is mapped to a wire or a wire with memory (i.e., a latch or FF). There is no direct hardware counterpart for variable and the synthesized circuit depends on the context in which the variable is used. The variable in VHDL is "static", which means that its value will be kept between the process invocations. This implies a variable may need to keep its previous value. Thus, a variable infers a latch or an FF if it is "used before assigned a value" in a process and infers a combinational circuit if it is "assigned a value before used". For this aspect, a variable is usually synthesizable. I personally use variable in a very restricted way: - don't use variable to infer memory - avoid self reference (e.g., n := n+1). - use it as shorthand for a function. Although I don't do it, this approach can even be used in a clocked process and obtain combinational, unbuffered, output (see my previous post on 1-process FSM example). In synthesis, the problem is normally the abuse of sequential statements, rather than the use of variable. I have seen people trying to convert C segment into a VHDL process (you can have variables, for loop, while loop, if, case, and even break inside a process) and expecting synthesis software to figure out everything. My 2 cents. Mike GArticle: 107499
jeffnewcomb@nci-usa.com schrieb: > Peter I would appreciate your help ! I have sent you an e-mail. > > I talked to Nu Horizons on Aug 28 and they say qty 3 of Engineering > Samples of the XC5VLX50-1FF676CES are not available until May 2007. I > am told by Nu Horizons only selected "big" customers can get samples. > The part we are wanting to buy is not any peculiar combination of > package-speed-temp range and not even a production version of the part. > I don't know what the supply of Virtex 5 looks like from Xilinx's side > but from the customer side of distribution the Virtex5 is not > available. I am not accusing Xilinx but am letting you know what > customers who want to design with the V5 are hearing. As a background > our company has been a Xilinx customer since 1990 and has bought > thousands of parts through the years. > > Peter Alfke wrote: > > V5LX50 have been available for several months. > > I don't want to get into a fight with your distributor, but he is > > feeding you nonsense data. > > Unless you want a peculiar combination of package-speed-temp range > > there should be no problem getting many samples now. > > If you have trouble, send me an e-mail. But I will be gone through > > labor day, Sept 4. > > Peter Alfke, peter@xilinx.com > > ========================== > > jeffnewcomb@nci-usa.com wrote: > > > I questioned the availability of the Virtex5 back in July on this group > > > and got some responses from Xilinx people saying it was being sampled > > > and to get a sample I needed to get an order in immediately. I did that > > > even though the parts were not even in distributors systems and the > > > local Xilinx reps initially were not sure what delivery would be. I > > > did get a response back from the rep saying there was a 13 week > > > delivery for an engineering sample which would be in late Sept. and you > > > could not get production parts until next year. I could live with that > > > and proceeded with my design using a V5LX50. Yesterday we got a FAX > > > from our distributor /rep saying delivery of the engineering sample > > > would not be until May 2007!!!. This is a full year after the part was > > > anounced. I have seen numerous advertisements for the Virtex 5 > > > "Shipping NOW". Does anyone know the truth behind this part ???? Are > > > there major problems with the part? To Xilinx, Jeff is not just talking - I have actually used products from his company. There are Xilinx FPGA inside. They are used pretty much to the maximum. It should be defenetly of Xilinx direct interest that his future products would also have Xilinx FPGAs inside. To be competitive he needs max fabric clocking frequency, and as some Xilinx competitors have new devices out with advertized 2GBit data rates on regular IOs then waiting til May 2007 isnt really an option for Jeff. Antti
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