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
Martin, We appreciate the feedback. However, your comment that "you would not send anyone to the classes" really hurts. That goes beyond your opinion of this one class, and indicts the whole program (unfairly, IMHO). Your description sounds like the folks in the class you were in were not at the right pre-requisite level, which means a great deal of frustration for the lecturer, and frustration for anyone in the class who expected the material to be useful. Again, I am only trying to see what went wrong (and give everyone the benefit of the doubt). Like I said, we are looking into this. Please give Xilinx educational services another look in the future, as our main interest is to enable the student to learn as fast as possible how to get their designs up, running, and in production. Austin Martin Euredjian wrote: > "Austin Lesea" wrote: > > > One bad review posted here does a lot of damage: and we are concerned > especially > > when we have hundreds of glowing reviews for the same class/instructor! > > Please understand that I meant this to be constructive criticism, meant to > help improve things, not cause damage. > > Let me give you my opinion as to why you have so many glowing reviews, at > least from the group I was with. > > In short: Corporate students. > > Pretty much everyone else at the class was from the same company. They had > been sent out on what I like to call a "corporate training tour". It's a > fun break away from the office and you get to learn something to boot. > > These guys took a number of courses during the same trip. At least one (and > probably more) of them was fresh out of school. I had a couple of good > conversations with him during breaks and realized that he did not belong in > that class at all. When I asked how much FPGA experience he had, he replied > that he'd just done the usual labs at school, not much more. > > I can't comment on every single person at the class, but you can learn a lot > about them based on the questions they ask. Again, it didn't seem that they > had enough time at the wheel. When the team leader is asking questions > about the I/O of a DCM block in an advanced class I pretty much know that > they didn't have a decent look through the VirtexII data sheet. Another > couple of guys were asking about how to configure Select I/O in order to > have series termination. They were also asking about good development > boards, etc. > > In general terms, to the uninitiated, the class was wonderful. If you are > too lazy to learn the basics (ok, to be fair, maybe didn't have the time?) > then the class exposed you to a lot of interesting information that, if > researched further, would result in valuable learning (wheen you are coming > from that context). For someone without the experience this class was > rocket science and you probably left in awe of all that's possible. > > Then there's the "I'm happy to be out of the office" effect. Everyone is > happy to do that. At least when you are part of a large corporate entity > and you are very detached from the financials. You'll probably get raving > reviews out of this group as well. > > Lastly, it takes caring and ... well ... balls to say what I'm saying. What > does a rank-and-file guy gain by saying that the class wasn't adequate? > Zilch. > > As a small business owner who actually pays the bills, designs hardware, > writes code, etc., etc., I'm intimately aware of the value of time and > money. I came to the class with a completely different frame of reference. > That's why you are not getting my stamp of approval by default, which is > what I think most attendees tend to do. > > Thanks for looking into it, > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Martin Euredjian > > To send private email: > 0_0_0_0_@pacbell.net > where > "0_0_0_0_" = "martineu"Article: 61551
James,
Before coding, you want to start with a good picture
of the hardware in your mind (or even better on paper).
Your code probably has a few surprises in it. There is
a register on DataIO and on OutEn. Is this what you wanted?
First a couple of HDL principles
1) Any signal assignment in a clocked process (one that
has "wait until Clk='1'", or an if expression with 'event or rising_edge).
2) Always code tristates separate from all other logic
(avoids a number of issues).
3) Don't code things that your hardware implementation
already guarantee's (such as read and write being
mutually exclusive - if you need to check them, then
use an assert statement).
What I would suggest is to write it as three separate
pieces of code.
1) A register bank that accepts writes to the correct address
2) A Multiplexer for read back
3) A Tristate
Recoding your design a little:
-- Writing to register bank
RegBankProc : process(Clk) begin
if rising_edge(Clk) then
if Write = '1' and ChipEnable = '1' then
case Addr is
when "00"=> Reg0<=DataIo;
when "01"=> Reg1<=DataIo;
when "10"=> Reg2<=DataIo;
when "11"=> Reg3<=DataIo;
when others =>
-- report not required, but good for validation
report "address invalid during valid write"
severity error ;
end case ;
end if ;
end if ;
end process ;
-- Readback Multiplexer
ReadBackMuxProc : process(Addr, Read)
begin
DataIo_int <= (Others => 'X') ; -- Default value if not read
if Read = '1' and ChipEnable = '1' then
case Addr is
when "00"=> DataIo_int <=Reg0;
when "01"=> DataIo_int <=Reg1;
when "10"=> DataIo_int <=Reg2;
when "11"=> DataIo_int <=Reg3;
when others =>
-- report not required, but good for validation
report "address invalid during valid read"
severity error ;
end case ;
end if ;
end process ;
-- Tristate (process also ok)
with OutEn select
DataIo <=
DataIo_int when '1',
(others => 'Z') when '0',
(others => 'X') when others ;
-- Check for bad things,
-- not required, but good for validation
-- addresses issues in your code without creating hardware
assert not (ChipEnable='1' and Read='1' and Write='1')
report "Read and Write asserted simultaneously"
severity ERROR ;
Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
James Williams wrote:
> Hello,
>
> I am just now learning VHDL and am wondering how I work write code to use
> one single 8bit in/out pins, which is mapped to 4 internal 8bit registers,
> which can either be read or written too. It of course would has a 2 bit
> address select. I know how to do the entity declaration, I'm not quite sure
> how to do the arch process. Here is what I am thinking, please tell me if I
> am doing this wrong.
>
> Note also that this is just an example on not my actual project.
>
>
> entity myMemory is
> port (Clk : in std_logic;
> DataIo :inout std_logic_vector (7 downto 0) Bus :=(others=>'Z');
> OutEn : in std_logic_vector; --Enables the output buffers.
> Write : in std_logic; --Write to memory " Active low"
> Read : in std_logic; --Read from memory "Active low"
> Addr : in std_logic_vector (1 downto 0));
> end myMemory;
> architecture Behavioral of myMemory is
> signal Reg0 : std_logic_vector (7 downto 0);
> signal Reg1 : std_logic_vector (7 downto 0);
> signal Reg2 : std_logic_vector (7 downto 0);
> signal Reg3 : std_logic_vector (7 downto 0);
> begin
> process(Clk) begin
> if(Clk'event and Clk='1') then
> case Addr is
> when "00"=>
> if(Read='0' and Write='1' and 'OutEn='1') then
> DataIo<=Reg0;
> elsif (Read='1' and Write='0' and OutEn='X') then
> Reg0<=DataIo;
> else DataIo<=(others=>'Z');
> when "01"=>
> if(Read='0' and Write='1' and 'OutEn='1') then
> DataIo<=Reg1;
> elsif (Read='1' and Write='0' and OutEn='X') then
> Reg1<=DataIo;
> else DataIo<=(others=>'Z');
> when "10"=>
> if(Read='0' and Write='1' and 'OutEn='1') then
> DataIo<=Reg2;
> elsif (Read='1' and Write='0' and OutEn='X') then
> Reg2<=DataIo;
> else DataIo<=(others=>'Z');
> when "11"=>
> if(Read='0' and Write='1' and 'OutEn='1') then
> DataIo<=Reg3;
> elsif (Read='1' and Write='0' and OutEn='X') then
> Reg3<=DataIo;
> else DataIo<=(others=>'Z');
> when others =>
> if(OutEn='0' then DataIo<=(others=>'Z');
> end if;
> end case;
>
> end if;
> end process;
> end Behavioral;
Article: 61552Pierre-Olivier, The simple answer is yes, the phase shifting feature has been used to avoid the switching region of the clock signal. If the DCM is used for this purpose, it will automatically adapt for phase shift with temperature, voltage, so you won't have to. There are fixed phaseshift modes where you find the best place to sample, and then change the phase constant, or modes where the phase shift is variable and you either train on-line (or off-line) and use the resulting phase shift that gave the best result. If the clock and the data are really asynchronous, no amount of phase shifting will ever remove the possibility of metastability. But if the issue is one of known frequency, but unknown phase, then a self-training DCM phase shift design might solve the problem. Austin PO Laprise wrote: > Just out of curiosity, has anyone ever used the phase-shifting > capabilities of the Xilinx DCMs to implement an adaptive clocking > circuit to avoid metastability? Once the clocks are in phase, what's > the standard drift, i.e. how often would it be necessary to verify if > the phase relationship is still right? Are there any reasons not to do > this? > > Pierre-Olivier > > -- to email me, remove the obvious from my address --Article: 61553
Followup to: <r4ggb.35497$Hb.553584@news4.e.nsc.no> By author: "Panic" <panic74@hotmail.com> In newsgroup: comp.arch.fpga > > So I had to decise how I would send and recieve my data. And this > is my main question, my design question: > > Would I be best off using say 64 pins for input and 64 pins for output, > and solve my problem that way, or could I use a bidirectional solution, > where I alternate on recieving and sending data over a 128 bits bus? > Impossible to tell without knowing what your application is, i.e. what "SubBlock" contains. Typically, a bidirectional bus will provide higher throughput in any one direction, but it costs time to turn around. Thus, if you are continuously processing data (let's say that you're doing an AES stream encryptor), you'd be better off with separate input and output busses, even at half width, but if you will be communicating in one direction at any one time then one bidirectional bus will serve you better. Also, in the case of the split bus solution, consider whether or not it is practical in your application to double-clock the 64-bit busses. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! If you send me mail in HTML format I will assume it's spam. "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64Article: 61554
Followup to: <bae769a6.0310060635.580b510c@posting.google.com>
By author: irum4@yahoo.com (irum4)
In newsgroup: comp.arch.fpga
>
> I have developed the PCI-device for which it is necessary 128 bytes of
> ports of input-output, 512 Kb of memory and one interrupt.
> When I install 4 devices simultaneously, BIOS allocates for them
> necessary resources, windows 98 allocates resources only for 3
> devices.
> And Windows XP at all it does not want to be loaded ("Blue screen"
> before installation of drivers).
>
Check through *all* the bits in the configuration space header to make
sure you match the specification.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
Article: 61555"Austin Lesea" wrote: > However, your comment that "you would not send anyone to the classes" really > hurts. That goes beyond your opinion of this one class, and indicts the whole > program (unfairly, IMHO). I looked back through my posts to see what you are referring to. The best I could find was: "Within the next few months I'll probably have a need to hire a couple of FPGA/Embedded guys, and the realization that I can't seem to rely on even sending them to a manufacturer-provided course in order to enhance their ability to generate accurate designs that perform well is what triggered some of my concern." I don't think that I said I would not send anyone to a class. Particularly not in a terminal sense. I sincerly believe that there's a lot of value in sending people to good courses. I've been to a few where, in the span of a week, I went from able-but-disorganized to knowing exactly where to go and huge gains in productivity. So, clearly, nobody in their right mind can state conlusively and absolutely that any and all classes are worthless. At least that's my experience. I have no doubt that Xilinx offers great courses. The begineer courses are probably very valuable in getting people up and running quickly. I know that when I was getting started I good kick in the right direction would have saved tons of time and money. I think that the problem might be that there was a disconnect between what the class was supposed to be and the level of experience/knowledge of the instructor (or, at least, what came out during the class). I'd expect a class tagged as "advanced" to be taught by someone like you, or, perhaps, outside experts in the field, some of whom participate in this n.g., like Ray Andraka. That's what I thought the class would be about. A humbling, yet enlightening experience. I would have expected to dive into some juicy and difficult topics, like, how to layout a folded FIR filter to improve performance. Or, the advantages/disadvantages of using SRL's instead of FF's for the main pipe of the filter. Data path alignment techniques. You get the idea. If the course cost $5K, so be it. Money is not the issue here. I'll repeat a few lines from a prior post: "Still, this is not a Xilinx putdown but rather constructive criticism. I love the chips and will probably continue to use them for a long time. I have over half a dozen high-performance imaging products in the works and, at this point, all of them have Xilinx FPGA's in them." > Your description sounds like the folks in the class you were in were not at the > right pre-requisite level, which means a great deal of frustration for the > lecturer, and frustration for anyone in the class who expected the material to > be useful. Maybe so. A few suggestions: 1- Have an online quiz of some sort as a way to grade potential students. 2- Have detailed bios on the instructors, including level of design experience, etc. 3- Make class documents (books, slides) available for purchase prior to committing to a class. Credit the cost towards taking the class within a given period of time. 4- Offer the ability to have registered students send questions to the instructor prior to attending the class. Perhaps a statement of who they are and what they want to get out of the class. 5- Have students describe current designs they may be working on and how this relates to wanting to take a class. 6- An advanced class should probably be a week-long class. Maybe that was the main problem here. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 61556
Martin, "Advanced" is not very definitive, I'll be the first to admit..... Still working the issue(s). No basic disagreeements here. You found the text to which I was referring, and it was not an endorsement of the course(s) at all. That was my point, so I thank you for restating it specifically for the one course in question (rather than for "a course" which implies any or all). AustinArticle: 61557
Austin Lesea wrote:
> PO Laprise wrote:
>
>>Just out of curiosity, has anyone ever used the phase-shifting
>>capabilities of the Xilinx DCMs to implement an adaptive clocking
>>circuit to avoid metastability? Once the clocks are in phase, what's
>>the standard drift, i.e. how often would it be necessary to verify if
>>the phase relationship is still right? Are there any reasons not to do
>>this?
>>
> Pierre-Olivier,
>
> The simple answer is yes, the phase shifting feature has been used to
> avoid the switching region of the clock signal.
>
> If the DCM is used for this purpose, it will automatically adapt for
> phase shift with temperature, voltage, so you won't have to.
>
> There are fixed phaseshift modes where you find the best place to
> sample, and then change the phase constant, or modes where the phase
> shift is variable and you either train on-line (or off-line) and use the
> resulting phase shift that gave the best result.
>
> If the clock and the data are really asynchronous, no amount of phase
> shifting will ever remove the possibility of metastability. But if the
> issue is one of known frequency, but unknown phase, then a self-training
> DCM phase shift design might solve the problem.
>
> Austin
Although in most cases it is probably not enough to worry about, the
phase might shift between the two devices due to differences in how they
age, or how temperature affects them. If one moves one way, the other
moves the other way, and the eye is small enough, it could spell trouble.
I wasn't responsible for the implementation, so I do not know the
details, but we do/did have an application that required using a DCM to
find the eye of the data (V2Pro wasn't going to be available in our time
frame, so we could not use the Rocket IO).
The phase shift is set up to be controlled by software, and they shift
it across across a wide band, inspecting the "data error" bit as they
go. Once they know where the good data eye is, they lock the DCM there.
The concept that the phase relationship could move over a very long
period of time had been brought up, but since I wasn't directly involved
with this, I do not know what solution was settled on. My suggestion
was to use a second DCM and monitor circuit to do a new sweep every so
often. If the monitor circuit finds that the main circuit is too close
to the edge of the data eye, the main DCM would be shifted by a few
digits to move it back close to the middle. The downside is that this
requires the duplication of a non-trivial amount of circuitry in our
case, not to mention chewing up DCM's pretty quickly if the number of
interfaces is gets very high.
Have fun,
Marc
Article: 61558Marc, You are describing just one of many interfaces that I have seen or heard of. Some use one DCM multiplexed across many others to find centers of bits (although this is tough to do as it requires multiplexed clocks). Others are not concerned with finding the center more than once, as they characterized the total phase shift external to the FPGA (internal phase shift is already updated/corrected constantly by the DCM). If it is V2 to V2, and two DCMs are used, one at the transmit, and one at the receive with a forwarded clock, then that again requires calibration once. Margin is the key: the less margin you have, the more difficult to solve the problem even with all the tricks you can possibly hide up your cleeves. Austin Marc Randolph wrote: > Austin Lesea wrote: > > PO Laprise wrote: > > > >>Just out of curiosity, has anyone ever used the phase-shifting > >>capabilities of the Xilinx DCMs to implement an adaptive clocking > >>circuit to avoid metastability? Once the clocks are in phase, what's > >>the standard drift, i.e. how often would it be necessary to verify if > >>the phase relationship is still right? Are there any reasons not to do > >>this? > >> > > Pierre-Olivier, > > > > The simple answer is yes, the phase shifting feature has been used to > > avoid the switching region of the clock signal. > > > > If the DCM is used for this purpose, it will automatically adapt for > > phase shift with temperature, voltage, so you won't have to. > > > > There are fixed phaseshift modes where you find the best place to > > sample, and then change the phase constant, or modes where the phase > > shift is variable and you either train on-line (or off-line) and use the > > resulting phase shift that gave the best result. > > > > If the clock and the data are really asynchronous, no amount of phase > > shifting will ever remove the possibility of metastability. But if the > > issue is one of known frequency, but unknown phase, then a self-training > > DCM phase shift design might solve the problem. > > > > Austin > > Although in most cases it is probably not enough to worry about, the > phase might shift between the two devices due to differences in how they > age, or how temperature affects them. If one moves one way, the other > moves the other way, and the eye is small enough, it could spell trouble. > > I wasn't responsible for the implementation, so I do not know the > details, but we do/did have an application that required using a DCM to > find the eye of the data (V2Pro wasn't going to be available in our time > frame, so we could not use the Rocket IO). > > The phase shift is set up to be controlled by software, and they shift > it across across a wide band, inspecting the "data error" bit as they > go. Once they know where the good data eye is, they lock the DCM there. > > The concept that the phase relationship could move over a very long > period of time had been brought up, but since I wasn't directly involved > with this, I do not know what solution was settled on. My suggestion > was to use a second DCM and monitor circuit to do a new sweep every so > often. If the monitor circuit finds that the main circuit is too close > to the edge of the data eye, the main DCM would be shifted by a few > digits to move it back close to the middle. The downside is that this > requires the duplication of a non-trivial amount of circuitry in our > case, not to mention chewing up DCM's pretty quickly if the number of > interfaces is gets very high. > > Have fun, > > MarcArticle: 61559
I have found the Micron MT48LC4M32B2TG SDRAM , 128MB, x32 config in 86pin TSOP to be readily available and are designing them in and have found the FBGA package availability of this part a bit concerning ... at least for smaller volumes for a smaller company. I also am going to buy production parts from the same vendor as my Cyclones ... so Mr. Salesman knows that he will only be receiving PO's for expensive parts if he gets my SDRAM. my 2c , KB On Mon, 06 Oct 2003 12:14:05 -0400, rickman <spamgoeshere4@yahoo.com> wrote: >I was discussing SDRAM a few weeks ago and I can't seem to find it in >this newsgroup. I guess it had gone to email. I have finally had a >chance to go on the web and take a look at some of the sources and I am >finding information hard to come by. I only find four main companies >making parts in either x32 arrangements or in small packages. They are >Micron, Samsung, Elpida and Hynix. I know there are a few "also ran" >companies making parts, but they don't seem to have the small packages >or the wide bus. > >Does anyone know if these parts in the small FBGA or TSSOPs packages are >shipping and if the availability is good? Any other makers than the >ones I listed above? > >-- > >Rick "rickman" Collins > >rick.collins@XYarius.com >Ignore the reply address. To email me use the above address with the XY >removed. > >Arius - A Signal Processing Solutions Company >Specializing in DSP and FPGA design URL http://www.arius.com >4 King Ave 301-682-7772 Voice >Frederick, MD 21701-3110 301-682-7666 FAXArticle: 61560
Yup. I've only taken one FPGA course ever. I'm not qualified to, nor can I offer opinion on other courses or training programs I know nothing about. I urge readers of this thread to keep this very clearly in mind. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message news:3F81EE71.AEBA3558@xilinx.com... > Martin, > > "Advanced" is not very definitive, I'll be the first to admit..... > > Still working the issue(s). No basic disagreeements here. You found the text > to which I was referring, and it was not an endorsement of the course(s) at > all. That was my point, so I thank you for restating it specifically for the > one course in question (rather than for "a course" which implies any or all). > > Austin > >Article: 61561
On Mon, 06 Oct 2003 12:14:05 -0400, rickman <spamgoeshere4@yahoo.com> wrote: >I was discussing SDRAM a few weeks ago and I can't seem to find it in >this newsgroup. I guess it had gone to email. I have finally had a >chance to go on the web and take a look at some of the sources and I am >finding information hard to come by. I only find four main companies >making parts in either x32 arrangements or in small packages. They are >Micron, Samsung, Elpida and Hynix. I know there are a few "also ran" >companies making parts, but they don't seem to have the small packages >or the wide bus. > >Does anyone know if these parts in the small FBGA or TSSOPs packages are >shipping and if the availability is good? Any other makers than the >ones I listed above? The main drivers in the SDRAM market are modules for computers. These seem to work best with x8 or x16 SDRAM chips. New x32 chips aren't so common. I recently had to source some DDRII SDRAM parts with a 32 bit bus, and ended up with two x16 parts. You may get lucky and find an older x32 part still in production (such as the one mentioned by Khim Bittle). Regards, Allan.Article: 61562
How do I specify the use of the F or G LUT in a slice? Can I? Does it matter? Why? How do you reduce wasted resources if you can't specify this in an RPM? The following code: //synthesis attribute RLOC of BIT[0].SRL is X0Y0 //synthesis attribute RLOC of BIT[1].SRL is X0Y0 //synthesis attribute RLOC of BIT[2].SRL is X0Y1 //synthesis attribute RLOC of BIT[3].SRL is X0Y1 ...etc. places SRLC16's from a Verilog "generate" block, but I can't seem to control which of the two LUT's is used for pairs of bits. The module in question generates a SRLC16-based delay block of variable (at instantiation) word size and delay. This is a building block for a FIR filter and I'd like to control placement as tightly as possible. Instead of getting a nice upward or downward sequential distribution, the above produces a sequence like this (assuming an 8-bit word): BIT[6].SRL (top-most slice SRL) BIT[7].SRL BIT[4].SRL BIT[5].SRL BIT[2].SRL BIT[3].SRL BIT[0].SRL BIT[1].SRL (bottom-most slice SRL) When, what I really want is: BIT[7].SRL (top-most slice SRL) BIT[6].SRL BIT[5].SRL BIT[4].SRL BIT[3].SRL BIT[2].SRL BIT[1].SRL BIT[0].SRL (bottom-most slice SRL) Thanks, -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 61563
Jonathan Bromley wrote:
> "zaf" <hsultan@utnet.utoledo.edu> wrote in message
> news:3aaabe6b.0310051158.5dd1f1b@posting.google.com...
>
>
>>Hello members...i need urgent help with a digital design problem
>
>
> It amuses me that student problems are invariably "urgent". By
> contrast, we who work in the commercial world of course have
> infinitely long timescales for our projects :-)
>
>
>>can some please help me expand the following function using shannon's
>>expansion theorem
>
>
> Not being an academic I have never heard of Shannon's expansion
> theorem, but Shannon was a pretty bright guy and I have no reason
> to doubt that he invented such a thing.
>
>
>>F = (A.B.C)'
>> = C' + A'C + AB'C
>
>
> It's useful to remember that you can write a multiplexer as
> a Boolean expression:
>
> Mux = in0.Sel' + in1.Sel
>
> represents a 2:1 mux selected by Sel, with inputs in0 and in1.
> To help with this Mux description, let's define that as a
> function M(in0,in1,Sel).
>
> So we can re-think your expression as multiplexers...
>
> F = C' + (A' + A.B').C
> = C' + C.M(1, B', A)
> = M(1, M(1, B', A), C)
>
> One more little observation:
> B' = 1.B' + 0.B
> = M(1, 0, B)
>
> Hey, I got one over on your prof! I don't need that OR gate at all!
>
> F = M(1, M(1, B', A), C)
> = M(1, M(1, M(1, 0, B), A), C)
>
>
> |\
> |\ 1-| |
> |\ 1-| | | |----F
> 1-| | | |------| |
> | |------| | |/
> 0-| | |/ |
> |/ | C
> | A
> B
>
> ASCII-schematic with thanks, as usual, to Andy Weber's wonderful
> AACircuit program (www.tech-chat.de).
>
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
>
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
> Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573 Web: http://www.doulos.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
>
>
>
The OP is referring to ACTEL's legacy ACT 1 FPGA family, their very
first but still supported. The basic Logic Module (LM) looks like so:
Please view in a fixed-width font such as Courier.
--
| \
A1 ---|1 \
| |
| |------+
| | |
A0 ---|0 / | --
| / | | \
-- | +--|1 \
| | |
SA --------+ | |-> F
| |
+--|0 /
-- | | /
| \ | -- |
B1 ---|1 \ | |
| | | |
| |------+ |
| | |
B0 ---|0 / |
| / |
-- | |
| |
SB --------+ |
|
|
__ |
S0 ---\ \ |
| >----------------+
S1 ---/__/
Shannon's theorem refers to the MUX expansion as you already explained,
but goes deeper into unique minterm expansion claims. Now try it- but
wait a week so the OP cannot claim extra credit on his assignment.:-)
Article: 61564
You have to add a BEL constraint to control which half of the slice pieces end
up in. There are six strings that are valid values for the BEL. I define a
couple of constant arrays to make them addressable with an index to make it more
amenable to being used with generates. In many cases you can get away without
the BELs, because for non-arithmetic logic it usually doesn't matter which half
of the slice the logic goes into. WHere it does matter is if you are using the
BX, BY inputs or carry chains. There are 3 pairs of BEL values, one for the
LUT, one for the flip-flop and one for the XOR_CY. The MUXCY's don't need it
because the position is inferred by the connectivity.
type bel_lut_type is array (0 to 1) of string (1 to 1);
type bel_ff_type is array (0 to 1) of string (1 to 3);
type bel_xor_type is array (0 to 1) of string (1 to 4);
constant bel_lut:bel_lut_type:= ("F","G");
constant bel_ff:bel_ff_type:= ("FFX","FFY");
constant bel_xor:bel_xor_type:=("XORF","XORG");
attribute BEL of U1:label is bel_lut(i mod 2);
attribute BEL of U3:label is bel_xor(i mod 2);
attribute BEL of U4:label is bel_ff(i mod 2);
attribute BEL of U5:label is bel_ff(i mod 2);
attribute RLOC of U1 : label is rloc_str;
attribute RLOC of U2 : label is rloc_str;
attribute RLOC of U3 : label is rloc_str;
attribute RLOC of U4 : label is rloc_str;
attribute RLOC of U5 : label is rloc_str;
Martin Euredjian wrote:
> How do I specify the use of the F or G LUT in a slice?
> Can I?
> Does it matter? Why?
> How do you reduce wasted resources if you can't specify this in an RPM?
>
> The following code:
>
> //synthesis attribute RLOC of BIT[0].SRL is X0Y0
> //synthesis attribute RLOC of BIT[1].SRL is X0Y0
> //synthesis attribute RLOC of BIT[2].SRL is X0Y1
> //synthesis attribute RLOC of BIT[3].SRL is X0Y1
> ...etc.
>
> places SRLC16's from a Verilog "generate" block, but I can't seem to control
> which of the two LUT's is used for pairs of bits.
>
> The module in question generates a SRLC16-based delay block of variable (at
> instantiation) word size and delay. This is a building block for a FIR
> filter and I'd like to control placement as tightly as possible. Instead of
> getting a nice upward or downward sequential distribution, the above
> produces a sequence like this (assuming an 8-bit word):
>
> BIT[6].SRL (top-most slice SRL)
> BIT[7].SRL
> BIT[4].SRL
> BIT[5].SRL
> BIT[2].SRL
> BIT[3].SRL
> BIT[0].SRL
> BIT[1].SRL (bottom-most slice SRL)
>
> When, what I really want is:
>
> BIT[7].SRL (top-most slice SRL)
> BIT[6].SRL
> BIT[5].SRL
> BIT[4].SRL
> BIT[3].SRL
> BIT[2].SRL
> BIT[1].SRL
> BIT[0].SRL (bottom-most slice SRL)
>
> Thanks,
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_" = "martineu"
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 61565Vazquez, Simon: Yes, the M4K blocks in Cyclone (and the M512 and M512K blocks in Stratix) are asynchronously clearable on their input and/or output registers (depends on the single/dual-port setup, etc.). And the M4K block can be configured in a mixed-width mode as described by Simon. - Paul Leventis Altera Corp.Article: 61566
Hi I have a design which takes about 74% resources on a sparta 3 1.5 m device. I am compiling on 5.2 sp3. The routing fails. In fact I tried lot of things but no use. Has anybody encountered similar problem. Thanks Rgd AnjanArticle: 61568
Hi, I've got Suse 8.1 on my machine and I'm trying to install Xilinx 6.1 sw. Admittedly they recommend RedHat, but I can't change the distribution just like that. Anyway, I follow the instructions: cd /media/cdrom ./setup I get the following error message : Wind/U Error (294): Unable to install Wind/U ini file (/media/cdrom/data/WindU). See the Wind/U manual for more details on the ".WindU" file and the "WINDU" environment variable. After a while, a window appears saying "Warning : no data files were found on CD image. The installation will be terminated". When I press ok, the installation finishes. The funny thing is that the directory "data" ((/media/cdrom/data/) on the cdrom is empty on the CD I've got. Can you help ? Shouldn't the "data" directory on the CD have something in it ? Thanks, ArthurArticle: 61569
Austin, > >Sorry you are not satisfied with the agreement, and the positive >response, and the acknowledgement and appreciation. > I never said any of those things. I certainly appreciate your (and Peter's) time spent monitoring the newsgroup. Thank you for the 'excellent list' comment. I ( and any future users of the LVDS_25_DCI standards ) also appreciate any prodding you can do to speed up the documentation process so others can have a less painful experience. However... I stand by Item 13 as originally written. It is an alert to potential users of V2 differential I/O of a critical component specification that they should be aware of before starting a design. You disagreed with me on this issue, so in subsequent posts I refuted the various arguments that you made contending that the high V2 C_COMP value is unavoidable/not a problem/etc. Instead of responding to my rebuttals, you changed the subject, ignored those portions of my posts, and now threaten to take your bat and ball and go home. > >No denial here. I explained why the capacitance is high. In fact, why in must be high, and why >we (and others) have no choice unless the LVDS inputs are dedicated in their own bank, with no >other standards attached (which no one wants in the FPGA world). > Instead of ignoring my previous posts, go download the ORCA-4 IBIS files, and take look at them: ALL OF THE GENERAL PURPOSE, NON-DEDICATED I/O STANDARDS HAVE A C_COMP VALUE OF 2pf. If they can do it, why can't you? I realize that the older families are unlikely to be improved, but if Xilinx won't admit the problem, at least internally, there's not as much hope for improvement in generation N+1. > >Our parts meet the LVDS standard, they work. > What about the other specs I have mentioned, such as HyperTransport, that have a tighter Cin or slew rate specification? > >If you use them wrongly, they don't work. > They work just fine, but only with proper care and feeding. > >As for wanting to "observe" the signal, that is about the best way to mess it up (which you aptly >point out). Rather than do that, how about using the existing variable phase shift feature to >measure the actual eye opening at the place where it counts: in the FPGA? Our customers that do >that are delighted that they no longer have to lose sleep over how much margin they have: they >measure it directly in the device itself. > Amazing: I write a clear, concise (IMHO) explanation of how having a BMFC on the device inputs make it impossible to probe, and you blame the probe!!! Life without probes is a fantasy: without a probe, I could have run IBIS simulations from here to eternity without finding out about the DCI amplitude modulation. The DCM phase shift is a very handy feature, but one must bear in mind that any measurements made in such a fashion, such as your SST IOB timing numbers, will also include DCM jitter. How is such an internal probe going to tell you anything about the input waveform other than its' threshold crossing time? What about amplitude, ringing, noise margin, or wacky, unexpected problems like the DCI modulation? > >You asked about the IBIS model, so I checked that. If the coupled/uncoupled t-line are an issue, >that is Mentor's responsibility. I hope you file bug reports with them if that is the case. > Ah, your response to this one quite aptly describes the sophisticated, iterative IBIS model debugging process that has been honed through years of industry experience: 1) Customer finds problem and calls IC vendor 2) IC vendor blames simulator vendor 3) Simulator vendor blames customer 4) Goto 1 ( apologies for the sarcasm, but I'm tired of arguing about this ) Brian Austin wrote: > >Brian, > >Wow. I agreed to move this up the list, and thanked you. Various CR (change requests) are now in >progress. > >I am so dissapointed. I agreed with you. I thanked you for putting all of the items in a nice >concise list. > >No denial here. I explained why the capacitance is high. In fact, why in must be high, and why >we (and others) have no choice unless the LVDS inputs are dedicated in their own bank, with no >other standards attached (which no one wants in the FPGA world). > >Our parts meet the LVDS standard, they work. If you use them wrongly, they don't work. If you >want 2pF inputs, go make your ASIC. That is how the ASIC/ASSP folks try to lock us out of their >markets. Unfortunately for them, there are plenty of folks who can not afford their devices, and >know how to properly simulate, and terminate and use capacitive inputs. > >As for wanting to "observe" the signal, that is about the best way to mess it up (which you aptly >point out). Rather than do that, how about using the existing variable phase shift feature to >measure the actual eye opening at the place where it counts: in the FPGA? Our customers that do >that are delighted that they no longer have to lose sleep over how much margin they have: they >measure it directly in the device itself. > >You asked about the IBIS model, so I checked that. If the coupled/uncoupled t-line are an issue, >that is Mentor's responsibility. I hope you file bug reports with them if that is the case. > >Sorry you are not satisfied with the agreement, and the positive response, and the acknowledgement >and appreciation. > >Austin > >Article: 61570
Thanks Ray, that did it.
Note to Xilinx:
Page 184 of the ISE6.1i Constraints Guide seems to have a typo: "FFT" should
be "FFY"
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian
To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"
"Ray Andraka" <ray@andraka.com> wrote in message
news:3F8220F4.920E48D3@andraka.com...
> You have to add a BEL constraint to control which half of the slice pieces
end
> up in. There are six strings that are valid values for the BEL. I define
a
> couple of constant arrays to make them addressable with an index to make
it more
> amenable to being used with generates. In many cases you can get away
without
> the BELs, because for non-arithmetic logic it usually doesn't matter which
half
> of the slice the logic goes into. WHere it does matter is if you are
using the
> BX, BY inputs or carry chains. There are 3 pairs of BEL values, one for
the
> LUT, one for the flip-flop and one for the XOR_CY. The MUXCY's don't need
it
> because the position is inferred by the connectivity.
>
> type bel_lut_type is array (0 to 1) of string (1 to 1);
> type bel_ff_type is array (0 to 1) of string (1 to 3);
> type bel_xor_type is array (0 to 1) of string (1 to 4);
> constant bel_lut:bel_lut_type:= ("F","G");
> constant bel_ff:bel_ff_type:= ("FFX","FFY");
> constant bel_xor:bel_xor_type:=("XORF","XORG");
>
> attribute BEL of U1:label is bel_lut(i mod 2);
> attribute BEL of U3:label is bel_xor(i mod 2);
> attribute BEL of U4:label is bel_ff(i mod 2);
> attribute BEL of U5:label is bel_ff(i mod 2);
> attribute RLOC of U1 : label is rloc_str;
> attribute RLOC of U2 : label is rloc_str;
> attribute RLOC of U3 : label is rloc_str;
> attribute RLOC of U4 : label is rloc_str;
> attribute RLOC of U5 : label is rloc_str;
>
> Martin Euredjian wrote:
>
> > How do I specify the use of the F or G LUT in a slice?
> > Can I?
> > Does it matter? Why?
> > How do you reduce wasted resources if you can't specify this in an RPM?
> >
> > The following code:
> >
> > //synthesis attribute RLOC of BIT[0].SRL is X0Y0
> > //synthesis attribute RLOC of BIT[1].SRL is X0Y0
> > //synthesis attribute RLOC of BIT[2].SRL is X0Y1
> > //synthesis attribute RLOC of BIT[3].SRL is X0Y1
> > ...etc.
> >
> > places SRLC16's from a Verilog "generate" block, but I can't seem to
control
> > which of the two LUT's is used for pairs of bits.
> >
> > The module in question generates a SRLC16-based delay block of variable
(at
> > instantiation) word size and delay. This is a building block for a FIR
> > filter and I'd like to control placement as tightly as possible.
Instead of
> > getting a nice upward or downward sequential distribution, the above
> > produces a sequence like this (assuming an 8-bit word):
> >
> > BIT[6].SRL (top-most slice SRL)
> > BIT[7].SRL
> > BIT[4].SRL
> > BIT[5].SRL
> > BIT[2].SRL
> > BIT[3].SRL
> > BIT[0].SRL
> > BIT[1].SRL (bottom-most slice SRL)
> >
> > When, what I really want is:
> >
> > BIT[7].SRL (top-most slice SRL)
> > BIT[6].SRL
> > BIT[5].SRL
> > BIT[4].SRL
> > BIT[3].SRL
> > BIT[2].SRL
> > BIT[1].SRL
> > BIT[0].SRL (bottom-most slice SRL)
> >
> > Thanks,
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Martin Euredjian
> >
> > To send private email:
> > 0_0_0_0_@pacbell.net
> > where
> > "0_0_0_0_" = "martineu"
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930 Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
> "They that give up essential liberty to obtain a little
> temporary safety deserve neither liberty nor safety."
> -Benjamin Franklin, 1759
>
>
Article: 61571> But you said that the clock was not truly asynchronous, but was 4 times > the data rate, with an unknown ( but stable?) phase relationship. > Maybe my description was a bit confusing, sorry for this. The clocks really are asychronous. There is no stable phase relationship between them, since the 27MHz clock is the ouput of a PLL locked on the H-Sync of a video signal, and the 108MHz system clock is derived from a 27MHz crystal oscillator.Article: 61572
>Perhaps a part of the registration process should require the students to >email the teacher a list of their most important questions, or list what >they're hoping to learn. If I knew enough to ask the right question I could probably find the answer myself. Or ask here, or ... The main reason I go to a class is to learn something about a topic when I don't know enough about it to ask the right questions. Another reason to go to a formal class is to get out of the office and away from your phone/email so you can concentrate on learning for long enough to make some progress. Sometimes you really do learn things by going through "dumb" lab exercises. (Especially if there is a good instructor who can answer questions when something interesting happens.) ------ It sounds like the main part of Martin's comments was a mismatched expectation about what "advanced" meant. Was there a good description of the course? Did the course match the description? Did a bunch of students show up who weren't ready for an "advanced" class? Maybe the instructor dropped back to their level without noticing that a few people were ready for a tougher course. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 61573
So...I have this little module that creates an RLOC'd SRL-based delay pipe that will feed one side of an adder in an FIR filter. Floorplanner confirms that the RLOCs are working as promised. However, if I instantiate more than one of these modules, only the first one is placed per the defined RLOCs and the rest are placed with SRL's and FF's outside of the required relative locations. I've looked through every report and I cannot find any warnings that would indicate that there's a problem of any kind. I also wrote and compiled a simplified version of the above to see if anything changed. The RLOC'd module consists of eight SRL's feeding eight FF's, RLOC'd to form a column. I instantiated two of these to then feed an 8-bit adder that clocks out to 8 FF's. The layout I got confirms the problem: The first module follows the RLOCs and the second does not. What's interesting is that section 7 of the MAP report lists two RPM's by their set name (for the last example) but section 13's "Number of RPM Macros" count is 1. Not sure where to go from here... -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 61574
"Plenolo" <plenolo@freemail.it> writes: > Hi all i am new in the group, i am a italian student of computer science and > i have hobbies for electronics, too... so i have using PIC, St6/7 > microcontroller, etc.. now my dream is develop some circuit with fpga (or > similar) and VHLD language. I have just a bit studing (only teorically) VHDL > in my university, but now i would REALLY program some chip for develop some > simple and medium project. > I have not money (and i don't want :-) ) to buy some original developing > system, so i would home build some free "programmer" (in-circuit JTAG ???) > how i have do in pass for PIC / St6/7 programmers :-) > You'd be better off on comp.arch.fpga, for the actual hardware questions - I've crossposted to there and set the followups to go there also. Regarding programming hardware, Altera have the Byteblaster schematics downloadable from their site, in the Byteblaster datasheet. I can;t recall if Xilinx have similar. > Thank you very much to all friends, and sorry for my very bad and poor > english language :-) > It's better than my Italian! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conekt
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