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
>From Xilinx Web site: Q1. Can XST pass generics in the command line? A1. This feature is currently not supported. Support for this feature is planned for ISE 9.1i. But you can pass generic via instantiation and/or at the top, use a package to define your constant. That's what I do and It works.Article: 99701
All-
I'm using Spartan 3 + XST 7.1sp4. In the code below, is there a way to
use a combinatorial always block and a for-loop to make it more
readable and not take 32 lines of source?
-Jeff
wire [31:0] a;
reg [7:0] b [31:0];
reg [2:0] bit;
assign a = {
b[31][bit],
:
:
b[10][bit],
b[9][bit],
b[8][bit],
b[7][bit],
b[6][bit],
b[5][bit],
b[4][bit],
b[3][bit],
b[2][bit],
b[1][bit],
b[0][bit]
};
Article: 99702Hi all, The design that I am working on is becoming increasingly difficult to debug and so I am trying to use chipscope pro. I tried some basic modules to familiarize myself with the tool and I have some basic questions about it. Can I capture more than 16384 samples? Can I capture more samples if I have a device with more gates than with lesser gates. i.e say XC3S200 Vs XC3S1500? I do not understand the concept of trigger ports. Suppose the whole design is based on the clock input to the fpga and the fpga is used as a memory controller, then what are the trigger ports? And should the output be triggered? I understand these are very basic questions and I tried to use google and the user guide to find the answer to this. If there are any basic documents that I can refer then please point me to it. Thanks Subhasri.KArticle: 99703
"Jeff Brower" <jbrower@signalogic.com> wrote in message
news:1143564063.943670.85530@i40g2000cwc.googlegroups.com...
> All-
>
> I'm using Spartan 3 + XST 7.1sp4. In the code below, is there a way to
> use a combinatorial always block and a for-loop to make it more
> readable and not take 32 lines of source?
>
> -Jeff
This should work:
integer i;
always @*
for( i=0; i<32; i=i+1 )
a[i] = b[i][bit];
Article: 99704The problem has been rectified as of 4:00 gmt yesterday. We appologize for any inconvenience this has caused. Tim Colleran Altera Corp.Article: 99705
Thanks John... XST complains that a is a wire. -JeffArticle: 99706
The Other Guy wrote: > I will investigate SystemC some more, although as it is based on C++ > classes, it was a route I was hoping to avoid (I prefer C). FpgaC > appears to be able to output VHDL as well, but I have been unable to get > any output from it that looks like it does anything other than > initialize values to 0. Yeah, that has been a pain for me too. Variable initialization is very high on the features development list for FpgaC as the cost to create a mux and assign values is much higher than "free' as initialization would offer. I'm not sure yet if it will be included in Beta-3 during April, or Beta-4 during June, but it will be part of one of the next two beta's.Article: 99707
Hello John, > >>Have you tried another brand of 16MHz clock oscillator? Farnell have >>heaps of alternative parts avaialble off the shelf in a variety of >>packages. > > What's a Farnell? > Bill is in Europe. Farnell is one of the distributors over there and AFAIK cooperates with Newark on this side of the pond. > > We could have sent them a small ferrite disk, to be glued into the top > of the board over the clock trace (we'd of course furnish a tube of > glue, no extra charge) that would fix it too. But I think the ROM swap > is more professional and managerial. > Cool. You could ship these in prescription med containers and call it "Extra Strength Larkinin" or something like that. With luck someone will later claim that they cure rheumatism and you'd have a new biz line that probably makes more money than anything before. Regards, Joerg http://www.analogconsultants.comArticle: 99708
16k is mx depth :( it is limited by the max address size of the BRAM eg chipscope is not using enables, to increase address rangeArticle: 99709
Sorry...
reg [31:0] a;
reg [7:0] b [31:0];
reg [2:0] bit;
integer i;
always @*
for( i=0; i<32; i=i+1 )
a[i] = b[i][bit];
"Jeff Brower" <jbrower@signalogic.com> wrote in message
news:1143566575.122908.265400@e56g2000cwe.googlegroups.com...
> Thanks John...
>
> XST complains that a is a wire.
>
> -Jeff
>
Article: 99710Hi Aurash, I believe this is a valid combination, according to Table 14 of the OPB specs. - dumak23Article: 99711
John- > reg [31:0] a; > reg [7:0] b [31:0]; > reg [2:0] bit; > integer i; > always @* > for( i=0; i<32; i=i+1 ) > a[i] = b[i][bit]; Well... I need a to be a wire. I guess there may not be a way to take advantage of for-loops with assign statements. -JeffArticle: 99712
On Tue, 28 Mar 2006 05:42:52 +0100, Isaac Bosompem <x86asm@gmail.com> wrote: > I think it is doing this because you are not using it as an input. Also > if you are working with FPGA's I think it would be a good idea to only > use unidirectional ports in sub modules. While using bidirectional > ports for top level devices (SDRAM, SRAM, Flash, etc.) > > -Isaac > I think it depends on actual FPGA. On those ones that support 3-state buffers in their units (e.g. Virtex) it's fine, if you really need it of course. On the other hand on something like Spartan, where 3-states are not supported (except IOs), implementation of 3states is based on logic chain which is, probably, not the best way :) -- AlexArticle: 99713
Hi Guru, I think you have to use the FPGA editor and extract the names of the signals. - dumak23Article: 99714
Greetings. I am looking to figure out a way to modify an existing BRAM controller (connected to either OPB or PLB) to add ECC capabilities. I am using EDK 7.1i, and it appears that controllers instantiated there cannot be modified. I have looked at Xilinx XAPP645 and understand how it works, but can't find a way to insert the VHDL into an existing controller. Basically, I'm trying to break the connection at PORTA such that the data will run through the ECC encoder to the BRAM, but the address and control lines are still intact (and connected to to the BRAM blocks). It seems like it should be a fairly straightforward exercise, but I have had zero success. The other part of the issue is that BRAM itself appears to be instantiated as part of the controller, so I also need to have a way to support the extra data as well. I appear to be getting BRAMs with the additional bit for parity data, but have no good way to access it. This is being done on a Virtex-II Pro, and I'm connecting to the PPC core. However, I don't think this is application-specific, since I should be able to do the same thing with a Microblaze, for example. Thanks!Article: 99715
"Jeff Brower" <jbrower@signalogic.com> wrote in message news:1143568299.707740.315120@i39g2000cwa.googlegroups.com... > John- > >> reg [31:0] a; >> reg [7:0] b [31:0]; >> reg [2:0] bit; >> integer i; >> always @* >> for( i=0; i<32; i=i+1 ) >> a[i] = b[i][bit]; > > Well... I need a to be a wire. I guess there may not be a way to take > advantage of for-loops with assign statements. > > -Jeff A doesn't need to be declared a wire to be a combinatorial value. Because the always block is a combinatorial block, the reg value is a combinatorial result, not implemented as a flip-flop or "register" primitive. The always constructs need reg-declared variables to work. Change "a" to reg per above. Compile. Realize. Smile.Article: 99716
On Mon, 27 Mar 2006 16:48:20 -0800, "Symon" <symon_brewer@hotmail.com> wrote: >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message > >> >> >> The unbonded pad thing sounds slick. I argued to use a real pin >> in-and-out as the delay element, but certain stingy engineers around >> here are unwilling to give up one of their two available test points. >> >> John >> >I sent you some stuff from my Hotmail account. If your spam filter blocks >it, let me know. >Best, Syms. > No, I got it, thanks hugely. That raises all sorts of possibilities for the future, what with pad capacitance, tristate drivers, strong and weak pullups, LVDS, all sorts of possible tricks. JohnArticle: 99717
On Tue, 28 Mar 2006 11:37:44 +1200, Jim Granville <no.spam@designtools.co.nz> wrote: >John Larkin wrote: >> On Tue, 28 Mar 2006 08:55:50 +1200, Jim Granville >>>Enable the schmitt option on the pin :) >> >> >> Don't I wish! There is a programmable delay element in the IO block, >> but it's probably a string of inverters, not an honest R-C delay, so >> it likely can't be used to lowpass the edge. We're not sure. >> >> I wish they'd tell us a little more about the actual electrical >> behavior of the i/o bits. I mean, Altera and Actel and everybody else >> has snooped all this out already. >> >>> >>>Since the issue is 'local', I'd fix it locally, and 2. sounds >>>preferable. You know the CLK freq, so can choose the delay banding. >> >> >> That's looking promising; we're testing that one now. Gotta figure how >> many cells it takes to delay 5 ns. (We'll just xor the ends and bring >> that out to a test point.) > > Yes, your main challenge will then be to persuade the tools to keep >your delay elements... > What is the pin-delay on the part - you could use that feature, >enable it on your pin, drive another nearby pin(s) (non bonded?) >and then use those as the S/R time-shutters. >-jg What's working now is my option #2, delay line with ANDs driving an r-s flop. The delay is eight internal buffers, giving us about 10 ns. We're using the midpoint tap, 5ns out, in the logic too, just in case. We ran tests on two boards, overnight, and it seems to work fine. We don't care about absolute delay or jitter here; if we did, we'd probably use Peter's circuit, which propagates clock edges but supresses additional transitions for a while. I shoulda thunk of that. Thanks to everybody for some great ideas. Several of the suggestions (internal ring oscillator, using unbonded pads, Peters's double-edge circuit) are good to know about. JohnArticle: 99718
Subhasri krishnan wrote: > The design that I am working on is becoming increasingly difficult to > debug and so I am trying to use chipscope pro. I tried some basic > modules to familiarize myself with the tool and I have some basic > questions about it. Can I capture more than 16384 samples? Can I > capture more samples if I have a device with more gates than with > lesser gates. i.e say XC3S200 Vs XC3S1500? The number of samples is limited by how many free RAMs you have in your device. I believe that the ChipScope docs make that point perfectly clear. > I do not understand the > concept of trigger ports. Suppose the whole design is based on the > clock input to the fpga and the fpga is used as a memory controller, > then what are the trigger ports? You trigger on whatever signals interest you. You might want to trigger when the memory controller writes to a particular address. > And should the output be triggered? If you want to see what happens when an output changes to a particular state, sure. > understand these are very basic questions and I tried to use google and > the user guide to find the answer to this. If there are any basic > documents that I can refer then please point me to it. Try reading Agilent's guides to using logic analyzers. -aArticle: 99719
moogyd@yahoo.co.uk wrote: > Hello, > > We have a parameterizable (via top level generics) VHDL design that we > are trying to put into an FPGA using the Xilinix XST (Version 7.1) > tools. > > We can't find any way within the tool of specifying values for the > generics as part of the build process. > > Are we not looking hard enough, or does the feature not exist ? Unfortunately, XST does NOT support this very useful feature that's been in the language since basically the beginning. It's worth noting that Quartus synthesis supports this feature. -aArticle: 99720
John- Bill Sloman has a point, you shouldn't be so hard on him. Many of our customers require a summary of what's been changed in a logic upgrade -- these tend to be the ones who know something about programmable logic. If we listed "clock deglitch" then there would be a good chance they would want more information, which might lead to more discussion about using a delay line based on buffers (or whatever is your fix), which might lead to us having to update boards in the field with a hardware fix to a hardware problem (at our cost). If one of my engineers omitted or lied about what we changed and I found out... well that's another problem, constrained by ethics and rules and not by creative thinking. I hope your fix is solid and based on sound engineering techniques, and your customer -- if they knew -- would be Ok with it. If so then I've missed the mark and I apologize in advance for chiming in. -JeffArticle: 99721
Subhasri, I believe you are confusing triggering with registering. Assuming you want to start acquision on memory write you could use WR as your trigger signal. The chipscope however allows for much more complex trigger events, but you should remember to connect to the trigger ports whatever signals you want to be a part of the triggering condition. /Mikhail "Subhasri krishnan" <subhasri.krishnan@gmail.com> wrote in message news:1143564884.718634.150560@i40g2000cwc.googlegroups.com... > Hi all, > The design that I am working on is becoming increasingly difficult to > debug and so I am trying to use chipscope pro. I tried some basic > modules to familiarize myself with the tool and I have some basic > questions about it. Can I capture more than 16384 samples? Can I > capture more samples if I have a device with more gates than with > lesser gates. i.e say XC3S200 Vs XC3S1500? I do not understand the > concept of trigger ports. Suppose the whole design is based on the > clock input to the fpga and the fpga is used as a memory controller, > then what are the trigger ports? And should the output be triggered? I > understand these are very basic questions and I tried to use google and > the user guide to find the answer to this. If there are any basic > documents that I can refer then please point me to it. > Thanks > Subhasri.K >Article: 99722
John-
> reg [31:0] a;
> reg [7:0] b [31:0];
> reg [2:0] bit;
> integer i;
> always @*
> for( i=0; i<32; i=i+1 )
> a[i] = b[i][bit];
> A doesn't need to be declared a wire to be a combinatorial value. Because
> the always block is a combinatorial block, the reg value is a combinatorial
> result, not implemented as a flip-flop or "register" primitive. The always
> constructs need reg-declared variables to work.
Ok, got it. I suppose I can think of it as a latch, always enabled.
But to let you know XST doesn't like the "*". To synthesize, I had to
use:
always begin
for (i=0; i<32; i=i+1)
a[i] = b[i][bit];
end
Is it equivalent? XST complains that b and bit are missing from the
sensitivity list.
-Jeff
Article: 99723
ywz.oct13@gmail.com wrote:
> for i in 1 to msgNum-1 loop
> -- msgNum is used as a range for variable "i"
In the future, please post questions like this to comp.lang.vhdl
> commenting the declaration does not seem to work. The error generated
> suggests that variables should not be used in range as the synthesis
> tool is unable to allocate resources as range is not fixed
Maybe msgNum is not declared properly:
constant msgNum : natural := 16;
> How should I approach the problem then?
Without a simulator:
trial and error.
look up some examples,
open a book,
google,
edit code,
compile, repeat.
With a simulator:
run a sim.
> Another question (not related to the above): I need a shared variable 2
> dimensional array for some concurrent processes which will update this
> array; however from what I read, shared variables should not be used
> for synthesis.
True.
By the way, that should be a synchronous process.
> What and how should I replace the shared variable with?
> signals??
With a single process design, you can use a regular variable array.
See the examples I referenced earlier.
> Btw, do you happen to know of any links where i can read up about the
> very basics of vhdl and synthesis?
Google is your friend:
> http://www.google.com/search?q=basics+vhdl+synthesis
-- Mike Treseler
Article: 99724Michael Schöberl wrote: > The biggest problem comes with "thinking in hardware" which turnes out > to be quite a problem for C-people ... the sequential way of planing > your programm usually does not fit very well and will waste a lot of > ressources ... The right vhdl template and design rules can cover most of the "thinking in hardware" bit and still allow a single threaded hardware description using variables, functions and procedures. See this discussion: http://groups.google.com/groups/search?q=%22using+standard+vhdl+synthesis%22 and this reference design. http://home.comcast.net/~mike_treseler/ -- Mike Treseler
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z