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
"methi" <gmethi@gmail.com> wrote in message news:1139937031.394518.220210@o13g2000cwo.googlegroups.com... > This is the vector diagram for 75% colorbars. > > Can you explain more about composite sweeps? > > Thank you, > > Methi What I meant in my original message was that if you have a color gradient from dark to light in one color with multiple components, the translation of those components to and from YUV space (for your vector diagram) could result in a set of color vectors that "curve" from the center to the outside by not tracking the U and V channels proportionally. If you're dealing with a solid color bar, any "curving" you see of the vectors on the analyzer should be a byproduct of the analyzer (going from off to on and back in a pixel's width). If your color is 100% U or V, increasing or decreasing the Y should give you a straight vector. If your color is a combination of U and V, the curving as Y is increased or decreased would be because U and V aren't properly proportional.Article: 97001
mattdykes wrote:
> Just upgraded to Xilinx ISE 8.1i (a bug for my part in 6.3i resulted in
> route errors) and am now getting syntax errors.(!) And neither errorno
> gets any hits in Xilinx's Answer Database.
>
> Offending code:
> port(...; enable_out: out std_logic;...)
> architecture...
> signal output_status: std_logic_vector(3 downto 0);
> begin
> ...
> enable_out <= '0' when output_status="0010" else '1';
> ...
> end
>
> Error:
> ERROR:HDLParsers:810 - "<filename>" Line <linenum>. = has two possible
> definitions in this scope.
>
> If I change output_status to std_logic, the error disappears so I
> assumed it had to do w/ signed/unsigned so code was changed to:
>
> enable_out <= '0' when output_status=unsigned("0010") else '1';
>
> Which resulted in this error:
> HDLParsers:3329 - "<filename>" Line <linenum>. Expression in type
> conversion to unsigned has 6 possible definitions in this scope, for
> example, std_ulogic_vector and std_logic_vector.
>
> Now entrenched in iterative debugging mode I change the code to:
>
> enable_out <= '0' when output_status=std_logic_vector("0010") else '1';
>
> New/same error:
> HDLParsers:3329 - "<filename>" Line <linenum>. Expression in type
> conversion to std_logic_vector has 6 possible definitions in this
> scope, for example, std_ulogic_vector and std_logic_vector.
>
> Aren't I defining it as std_logic_vector? I want to say it's a bug in
> ISE and I've registered w/ Xilinx support, but it'll probably be a few
> days before they let me on the server and have a solution.
>
> Also, this happens in processes, too, when comparing vectors in if
> statements - if that sheds anymore light.
>
> Anybody seen this? Understand why the error? I considered using
> constants for the literals, but I have the same problem elsewhere
> comparing dynamic vectors so it's not going to help me there. i.e.:
>
> addr_hit <= '1' when addr(31 downto BASE_ADDR_SIZE) = base_addr(31
> downto BASE_ADDR_SIZE) else '0';
>
> Any help/insight/suggestions would be greatly appreciated. Thanks -Matt
Matt;
I'm using ISE 6.2.03i, and had similar errors when casting to unsigned,
and also to std_logic_vector. That was quite a surprise, since your
code looked OK to me. But I'm certainly no expert.
I then tried using the "std_match" function, which is in the
"numeric_std" library, and that worked. I made output_status a port so
that I could verify the logic by looking at the RTL schematic.
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;
entity x is
Port ( enable_out : out std_logic;
output_status : in std_logic_vector(3 downto 0)
);
end x;
architecture Behavioral of x is
begin
enable_out <= '0' when std_match( output_status, "0010" ) else '1';
end Behavioral;
HTH
-Dave Pollum
Article: 97002I spoke with Avnet yesterday, and they told me they were getting a shipment of the starter kits in on march 9th. - Tom John_H wrote: > elf_ster@hotmail.com wrote: > >> They are shipping as we speak. There was a huge demand for it. > > > Huh? Who? What? Uh... Where from? > > I've been looking at the Xilinx Online Store and the digilentinc site > and have seen nothing. The only order entry I've seen was from > distribution and I didn't trust it to do any better than the first two > sources. I'm talking 3e starter kit, not the sample pack.Article: 97003
Thanks Duane.
Your comment helped me to sought out the problem.
I am again posting the whole code with previous problem rectified, but
with a new problem.
If you Guru's simulate all the files which I have provided, you will
find that the OUTPUT "matrix_output" (BASIC PROGRAM below) is
having a value 0080808080808080 latched since beginning, and these
latched values does not get removed.
Please point out the problem.
Thanks in advance.
--TOP LEVEL
library IEEE;
use IEEE.std_logic_1164.all;
entity numberINsorting_TB is
port(
CLOCK : in STD_LOGIC;
Reset : in STD_LOGIC
);
end numberINsorting_TB;
architecture numberINsorting_TB of numberINsorting_TB is
---- Component declarations -----
component counterForROM
port (
CLK : in STD_LOGIC;
CLR : in STD_LOGIC;
Q : out INTEGER range 0 to N-1
);
end component;
component numberINsorting
port (
Reset : in STD_LOGIC;
clock : in STD_LOGIC;
in_jala : in STD_LOGIC_VECTOR(M-1 downto 0);
in_ved : in STD_LOGIC_VECTOR(M-1 downto 0);
Z : out TYPE_IO
);
end component;
component romJALA
port (
ADDRESS : in INTEGER range 0 to N-1;
Q_rom : out STD_LOGIC_VECTOR(M-1 downto 0)
);
end component;
component romVED
port (
ADDRESS : in INTEGER range 0 to N-1;
Q_rom : out STD_LOGIC_VECTOR(M-1 downto 0)
);
end component;
---- Signal declarations used on the diagram ----
signal NET169 : INTEGER range 0 to N-1;
signal BUS56 : STD_LOGIC_VECTOR (7 downto 0);
signal BUS67 : STD_LOGIC_VECTOR (7 downto 0);
begin
---- Component instantiations ----
U1 : numberINsorting
port map(
Reset => Reset,
clock => CLOCK,
in_jala => BUS67( 7 downto 0 ),
in_ved => BUS56( 7 downto 0 )
);
U2 : romJALA
port map(
ADDRESS => NET169,
Q_rom => BUS67( 7 downto 0 )
);
U3 : romVED
port map(
ADDRESS => NET169,
Q_rom => BUS56( 7 downto 0 )
);
U4 : counterForROM
port map(
CLK => CLOCK,
CLR => Reset,
Q => NET169
);
end numberINsorting_TB;
---- Basic program
library WORK,IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_SIGNED.ALL;
use WORK.CONV.ALL;
entity numberINsorting is
port( in_ved: in std_logic_vector(M-1 downto 0);
in_jala: in std_logic_vector(M-1 downto 0);
clock,Reset,clock9x: in std_logic;
STAMP_var1,STAMP_var2,STAMP_var3 : out integer range 0 to N-1;
matrix_out : out MATRIX;
Z: out TYPE_IO);
end numberINsorting;
architecture BEHVnumberINsorting of numberINsorting is
signal ved: TYPE_IO ;
signal jala: TYPE_IO ;
-------------------------------------
--signal matrix_signal : MATRIX := (
-- ('0','0','0','0','0','0','0','0'),
-- ('0','0','0','0','0','0','0','0'),
-- ('0','0','0','0','0','0','0','0'),
-- ('0','0','0','0','0','0','0','0'),
-- ('0','0','0','0','0','0','0','0'),
-- ('0','0','0','0','0','0','0','0'),
-- ('0','0','0','0','0','0','0','0'),
-- ('0','0','0','0','0','0','0','0') );
----------------
begin
dataIN : process(clock,Reset)
variable count : integer range 0 to (N-1) ;
------------------------------------------------
-----------------------------------------------
begin
----------------------------------------------
if reset='1' then
count:=0;
else if rising_edge(clock) then
if count=(N-1) then
count:=0;
else
count:=count +1;
end if;
ved(count)<= in_ved;
--jala(count) <= in_jala;
end if ;
end if;
end process dataIN;
----------SORTING STARTS HERE----------
sorting : process(ved)
variable list : TYPE_IO ;
variable tmp : std_logic_vector(M-1 downto 0);
begin
list := ved;
for i in 0 to N-2 loop
for j in 0 to N-2-i loop
if list(j+1) > list(j) then -- compare the two neighbors
tmp := list(j); -- swap a[j] and a[j+1]
list(j) := list(j+1);
list(j+1) := tmp;
end if;
end loop;
end loop;
--Z <= list;
jala <= list ; ----- output array
end process sorting;
-------------SORTING ENDS HERE ----------
-----------------------------------------
-----------STAMPING STARTS HERE----------
stamping:process (clock9x,reset)
variable STS,STS1,STS2 : Boolean;
variable var_temp,VAR_TEMP1,var_temp2 : integer range 0 to N-1:=0;
begin
if reset = '1' then
STS := FALSE;
var_temp := 0;
var_temp1 := 0;
var_temp2 := 0;
else if rising_edge(clock9x) then
--------------------R AND D stamp-------------------
for k in 0 to N-1 loop
STS := ( ved(k) = jala(N-1) ) ;
if STS = TRUE then
var_temp := (k) ;
STAMP_var1 <= var_temp;
end if ;
STS1 := ( ved(k) = jala(N-2) ) ;
if STS1 = TRUE then
var_temp1 := (k) ;
STAMP_var2 <= var_temp1 ;
end if ;
STS2 := ( ved(k) = jala(N-3) ) ;
if STS2 = TRUE then
var_temp2 := (k) ;
STAMP_var3 <= var_temp2 ;
end if ;
end loop ;
----------------R AND D----------------------
end if; --end reset
end if; -- end clock
end process stamping;
----------------MATRIX FORMATION------------
Matrix_formation : process (clock9x)
----------------
variable matrix_var : MATRIX := (
('0','0','0','0','0','0','0','0'),
('0','0','0','0','0','0','0','0'),
('0','0','0','0','0','0','0','0'),
('0','0','0','0','0','0','0','0'),
('0','0','0','0','0','0','0','0'),
('0','0','0','0','0','0','0','0'),
('0','0','0','0','0','0','0','0'),
('0','0','0','0','0','0','0','0') );
----------------
begin
--if reset='1' then
--
-- matrix_signal <= (
-- ('0','0','0','0','0','0','0','0'),
-- ('0','0','0','0','0','0','0','0'),
-- ('0','0','0','0','0','0','0','0'),
-- ('0','0','0','0','0','0','0','0'),
-- ('0','0','0','0','0','0','0','0'),
-- ('0','0','0','0','0','0','0','0'),
-- ('0','0','0','0','0','0','0','0'),
-- ('0','0','0','0','0','0','0','0')
-- );
--else if rising_edge(clock9x) then
--else
matrix_var(1,stamp_var1) := '1' ;
matrix_var(2,stamp_var2) := '1' ;
matrix_var(3,stamp_var1) := '1' ;
matrix_var(3,stamp_var2) := '1' ;
matrix_var(4,stamp_var3) := '1' ;
matrix_var(5,stamp_var1) := '1' ;
matrix_var(5,stamp_var3) := '1' ;
matrix_var(6,stamp_var2) := '1' ;
matrix_var(6,stamp_var3) := '1' ;
matrix_var(7,stamp_var1) := '1' ;
matrix_var(7,stamp_var2) := '1' ;
matrix_var(7,stamp_var3) := '1' ;
matrix_out <= matrix_var;
-- end if ;
-- end if ;
end process Matrix_formation ;
--matrix_out <= matrix_var;
-----------------------------------------------
end BEHVnumberINsorting;
--ROM ved
library WORK,IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use WORK.CONV.ALL;
entity romVED is
port (
ADDRESS : in integer range 0 to N-1;
Q_rom : out std_logic_vector(M-1 downto 0)
);
end entity;
library IEEE;
use IEEE.std_logic_unsigned.all;
architecture romVEDarch of romVED is
begin
process(ADDRESS)
begin
case (ADDRESS) is
when 0 => Q_rom <= "1111"; -- F
when 1 => Q_rom <= "0000"; -- 0
when 2 => Q_rom <= "0011"; -- 3
when 3 => Q_rom <= "0001"; -- 1
when 4 => Q_rom <= "1100"; -- C
when 5 => Q_rom <= "1101"; -- D
when 6 => Q_rom <= "0101"; -- 5
when 7 => Q_rom <= "1000"; -- 8
--when others => Q_rom <= "0000";
end case;
end process;
end architecture;
library WORK,IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
--use IEEE.STD_LOGIC_SIGNED.ALL;
use WORK.CONV.ALL;
entity romJALA is
port (
ADDRESS : in integer range 0 to N-1;
Q_rom : out std_logic_vector(M-1 downto 0)
);
end entity;
library IEEE;
use IEEE.std_logic_unsigned.all;
architecture romJALAarch of romJALA is
begin
process(ADDRESS)
begin
case (ADDRESS) is
when 0 => Q_rom <= "1100"; -- C
when 1 => Q_rom <= "1101"; -- D
when 2 => Q_rom <= "0011"; -- 3
when 3 => Q_rom <= "0101"; -- 5
when 4 => Q_rom <= "1000"; -- 8
when 5 => Q_rom <= "1111"; -- F
when 6 => Q_rom <= "0001"; -- 1
when 7 => Q_rom <= "0000"; -- 0
--when others => Q_rom <= "0000";
end case;
end process;
end architecture;
---counter9x
--Changes will have to be made when frame size will be increasing
--
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_arith.all;
use WORK.CONV.ALL;
ENTITY counter9X IS
PORT(
clk : IN std_logic;
reset : IN std_logic;
clock9x : OUT std_logic
);
END counter9X ;
ARCHITECTURE arch_counter9X OF counter9X IS
BEGIN
-----------------------------------------
p0: process(clk,reset)
variable clk_var : std_logic;
--variable count : natural range 0 to 15;
variable count : integer range 0 to 17;
begin
if rising_edge(clk) then
if reset='1' then
clk_var :='0';
count:=0;
else
--------------------------------------
if count <= 8 or count >10 then
-- if count <= 13 or count > 15 then
-------------------------------------
clk_var :='0' ;
else
clk_var :='1' ;
end if;
clock9x <= clk_var;
if count=17 then
count:=0;
else
count:=count +1;
end if;
end if;
end if;
end process;
-----------------------------------------
END arch_counter9X;
---- counterFOR_rom
library WORK,IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use WORK.CONV.ALL;
entity counterForROM is
port (
CLK : in std_logic;
CLR : in std_logic;
Q : out integer range 0 to N-1
);
end entity;
library IEEE;
use IEEE.std_logic_unsigned.all;
architecture counterForROM_arch of counterForROM is
signal TEMP_Q : integer range 0 to N-1 ;
begin
process(CLK)
begin
if rising_edge(CLK) then
if CLR = '1' then
TEMP_Q <= 0;
else
if (TEMP_Q = N-1) then
TEMP_Q <= 0;
else
TEMP_Q <= TEMP_Q + 1;
end if;
end if;
Q <= TEMP_Q;
end if;
end process;
end architecture;
Article: 97004"Andy Peters" <Bassman59a@yahoo.com> wrote in message news:1139867687.548530.91980@g43g2000cwa.googlegroups.com... > richard wrote: >> If >> the senior engineers, and I don't mean those kids who don't even >> remember back before there was a NASA, are presented with a single-page >> schematic, they can grasp what's going on in the design, at least to >> their own satisfaction, with the help of the documentation, in about a >> half an hour. > > Good luck fitting a modern design on a single schematic sheet. Unless, > of course, that sheet is Z size, or whatever. That's the way a newbie would go about it. I exclusively use 'schematic' (Quartus) for all my fpga work. I have been designing digital processing systems all my working life (since 1968) and using CPLD/FPGA since around 1987. I do not design micky mouse systems either - am involved in design of massively parallel image processing systems all the time. Best way is to create a hierachical design from the bottom up - I may use 1 sheet for perhaps a feature extractor for example, design for the target device, create test benches and thoroughly test, then create a symbol for that function. That function can then be used as many times as you like at higher levels of the design. The top level design brings together all the tested sub functions. Its easy to see whats going on. Before any of you VHDL guys start shouting - ahhh but its much quicker using a description language I will say that most of my designs work first time - and I have always got there much faster than any guy writting high level in any language - and with a fully documented, easily modified design. Designing at schematic level does NOT necessarily mean gate/counter level either, a single component may easily be a complex processing function. SlurpArticle: 97005
Symon wrote: > It's got to the point where I've looked (unsuccessfully) for tools to do > some PCB design entry using VHDL. I'm getting sick and tired of drawing a > bunch of rectangles with hundreds of wires coming off them to represent an > FPGA. Also, adding each and every bypass cap. If I could use VHDL for this, > I could cut and paste a lot of the pin information from the data sheet to be > more accurate and quicker. Of course, for analog electronics this makes > little sense, but it would be nice to be able to mix and match the two entry > methods. The better PCB packages will allow ASCII Merge (multi import) of NetLists - so you could use scripts to create a PCB FPGA netlist, from the Pin reports, for example. That does properly track Changes. I think you'd still want the Caps, and FPGA itself in the SCH :- that gives correct BOM, and in many cases you can build parts with SIGPINS that invisibly connect to GND, + 3.3V etc - so your CAPS and FPGA symbols could have NO manual connections needed. -jgArticle: 97006
Hey guys I am actually using a CPLD by Altera Max 7000S. I have an output pin that needs to either be tristated or drive a '1' at all times other than when driving data on the bus. I have used the second option up until now and it has some weird glitches since it is inside a process and until it gets the first clock it doesnt go to '1'. Maybe if there was a way to initialize it to a '1' at power up. I think the best way is to do a tristate, but I have very little resources left. Matt "Aurelian Lazarut" <aurash@xilinx.com> wrote in message news:dst25d$g1t2@cliff.xsj.xilinx.com... > radarman wrote: >> Check the data sheet for your part. Some parts will allow for true >> *internal* tri-states, while others do not. For example, a Xilinx 4000 >> series FPGA will do true internal tristates, while neither the Virtex >> nor Spartan series FPGA will not. > Actually they do have. > Spartan2 spartan2E virtex and virtexE they all have BUFT (or TBUFS) > > parts without BUFTs: virtex2/pro virtex4 spartan3/3E > > Aurash >> >> For parts that do support it, you will need to add a line like this >> (for VHDL): >> >> TSTATE_BUS <= My_bits when Enable = '1' else (others => 'Z'); >> >> Note, you can still do this even in later families, but the compiler >> will turn it into a mux - so be careful. If you aren't aware of that >> behavior, you can be surprised on large designs with low LUT margins. >> >> Note, I have seen some IP cores that use an 'OR'ed bus structure to >> solve this problem. With an OR type bus, you just drive zeros when not >> enabled: >> >> arcitecture rtl of sample is >> >> -- To simplify the OR logic, make these the same width. Your >> compiler/synthesizer should optimize away bits you don't need - while >> still making the correct connections. Just load the registers you DON'T >> need with a constant value. >> signal My_Bus_1_d, My_Bus_1_q : std_logic_vector( BUS_WIDTH_MINUS_1 >> downto 0 ); >> signal My_Bus_2_d, My_Bus_2_q : std_logic_vector( BUS_WIDTH_MINUS_1 >> downto 0 ); >> >> -- Don't worry too much about the My_Data_n busses - you can pad the >> bus when you feed it to My_Bus_n_d; >> signal My_Data_1 : std_logic_vector( 3 downto 0); >> signal My_Data_2 : std_logic_vector( 15 downto 0); >> >> begin >> >> -- You need one of these per *readable* register/entity >> My_Bus_1_d <= My_Data_1 when Enable_1 = '1' else (others => '0'); >> My_Bus_2_d <= My_Data_2 when Enable_2 = '1' else (others => '0'); >> >> -- To keep your combinational logic path to a minimum, register each >> "My_Bus". This isn't necessary, and does add an additional clock of >> latency, but if your timing is marginal, this will help. >> >> S_Regs : process( Reset_n, Clock ) >> begin >> if( Reset_n = '0' )then >> My_Bus_1_q <= (others => '0'); >> My_Bus_2_q <= (others => '0'); >> elsif( rising_edge(Clock) )then >> My_Bus_1_q <= My_Bus_1_d; >> My_Bus_2_q <= My_Bus_2_d; >> end if; >> end process; >> >> -- Then, you need _only_ one of these somewhere in the code to "mux" >> the bus together. >> for i in BUS_WIDTH_MINUS_1 to 0 loop >> OR_BUS(i) <= My_Bus_1_q(i) or My_Bus_2_q(i); >> end loop; >> >> end rtl >> >> This is fairly resource intensive, but it is fast, and explicit. To >> improve performance, I would suggest registering My_Bus_n as shown - >> unless your design has few readable registers - or you can tolerate the >> long combinational paths. BTW - if you look closely, you will see that >> this only handles the READ portion of your bus. Use a separate bus for >> handling writes. Not only will this improve performance, since you >> don't have to simulate bus turnaround, but you don't need any muxing at >> all for a WRITE bus - just clock enables on the registers. Saves a lot >> of grief in the long run. >> >> Good luck! >>Article: 97007
Slurp, I like your approach, but I think you really have to start with a top-level block diagram that describes how you intend to solve the overall problem. Then you solve it in chunks, from the bottom up... I think age and experience strongly influences these choices... Peter AlfkeArticle: 97008
"Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote in news:45eg2iF6cp26U1@individual.net: >> Sometimes, I think that the Europeans think that all products are >> like consumer items that have a product life of a few months or maybe >> a year (like a PC or cell phone). > > > Al, > > Please don't tarr us all with the European 'politician's brush, they > just _don't_ think. > > A couple of weeks ago someone on sci.electronics.design (I think) > posted a link to a presentation that quoted TI's figures, that a > worldwide conversion to lead free packages would save about the same > amount of lead as in TEN car batteries. > > The european parliament is a complete waste of time and a huge waste > of money. > > > Nial. > > > Fair enough, We sell our products to many European companies, both small and large. I sure many EU based companies are struggling with these same issues. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.comArticle: 97009
> > The european parliament is a complete waste of time and a huge waste > of money. > > > Nial. > > It's even worse. The political people that decided to go for the RoHs rules made it even worse. In order to avoid the lead, you have to poison the environment more, because you need a substitute for lead and the separation process for lead needs more energy and more critical process steps. In the end, we have no lead, but many new problems. That's the way it works if you ask the political guys to do something ... ... and there is more to come in that direction ... BTW some industries have a permission for not being RoHs compliant. For example Cars, Trains, Medicine, Aircrafts etc. All the areas where a lot of lead is being used these days. At the end we end up with more legal rules and no real advantage of having to follow these rules ... "This is just another brick in the wall" to lower our competition, in the global market ... really nice time to come ..." Also these guys do not have a clear answer on : "What has to be done for all the situations where a 100 % RoHs transition is just not possible, because the parts are not available. But as in most cases these 'stupid' and 'boring' real life details do not really interest the political guys. Ha ... MarkusArticle: 97010
Sky wrote: > In a project I use the Altera EPM3256ATC144-10. > Now I have the necessity to make some changes to the project, but I don't > have enough macrocells in the actual devices. > Alteras doesn't have a pin-to-pin compatible EPLD with the EPM3256ATC144-10 > but with more macrocelles (about +40%). > What of you knows a devices that could resolve my problem? Unfortunately I > cannot modify the PCB, but I could replace the Altera EPLD with any other > CPLD. > Thanks If you do not want to modify the PCB, you could use an IC adapter package. We used a company ISI, www.isipkg.com They implemented a footprint from an obsolete part to a Lattice XP device.Article: 97011
Thanks, Dave. I'm a dumb arse. I'm finishing up a project for a co-worker and didn't notice he was using every library know to man. Note to self: Don't include ieee.std_logic_signed.all AND ieee.std_logic_unsigned.all.Article: 97012
Hi all, I have two questions regarding the OPB usage. 1) why is it the microblaze connects to the IOPB port to the OPB bus when running from internal memory (BRAM) ? the program runs only from the ILMB isn't it? 2) PLB-OPB bridge , the PPC405 reference guide says that the PLB should be used for fast bus transactions and that the OPB is to be used for slower peripherals (GPIOs/UART etc.). My question is as follows - If I'm using a PLB-OPB bridge the data from/to the OPB will still go trough the PLB bus so how come it is says the the OPB usage takes some load of the PLB bus ? Thanks, Mordehay.Article: 97013
I'll refrain from commenting on the environmental merit of lead-free devices. I did a quick check of inventory on a representative distributor (Arrow Electronics North America) web site. Most MAX 3000A and Cyclone devices (picking 2 representative product families) have similar lead-times for both leaded and lead-free (RoHS compliant) versions. Altera's minimum order quantities are the same for both devices. We have put in place a rigorous (though clearly not perfect) plan to facitate the transition to lead-free product. This is severely complicated by the fact that not all customers have interest in immediately converting all devices to lead-free product, which generally has a different manufacturing flow. As a result we need both leaded and lead-free ordering codes for most devices and most of these lead-free ordering codes have been in place for several quarters. You can find a complete listing of Altera's lead-free solutions at http://www.altera.com/products/devices/leadfree/lead-free_index.html Dave Greenfield Altera Marketing >Today I got this in Altera's email newsletter >Get RoHS Compliant with Altera FPGAs, CPLDs and Structured ASICs >I have never seen a single 3000 series PLD available in leadfree that you >could actually purchase for delivery from stock. I have been able to buy >lead versions of most of this family without too much trouble. . . .Article: 97014
I recommend reading the article below: http://www.fpgajournal.com/articles_2006/20060207_cray.htm Apparently RC works... Peter AlfkeArticle: 97015
Hi all, I have 2 questions on different ways of using BRAM in EDK: 1. I have created a PPC system with DSOCM_BRAM and I am trying to make one side of it external for some external logic to access. The block is only 32 KB, but EDK would not allow me to set the address bus width (C_PORT_AWIDTH) to below 32 bit... This is confusing as according to the BRAM Block datasheet C_PORT_AWIDTH cannot be bigger than 17! So, should I just ignore extra pins or what? 2. In the same system I have PLB_BRAM, which I want to be let's say 100 KB. However, the EDK seems to only accept a power of 2 size, i.e. either 64 KB or 128 KB. I was hoping that I could configure the controller for 128 KB range but physically assign a smaller block of memory to it. Is this possible? Thanks, /MikhailArticle: 97016
"Dave Greenfield" <davidg@altera.com> wrote in news:1139953661.537335.166000@o13g2000cwo.googlegroups.com: > I'll refrain from commenting on the environmental merit of lead-free > devices. > > I did a quick check of inventory on a representative distributor (Arrow > Electronics North America) web site. Most MAX 3000A and Cyclone devices > (picking 2 representative product families) have similar lead-times for > both leaded and lead-free (RoHS compliant) versions. Altera's minimum > order quantities are the same for both devices. We have put in place a > rigorous (though clearly not perfect) plan to facitate the transition > to lead-free product. This is severely complicated by the fact that not > all customers have interest in immediately converting all devices to > lead-free product, which generally has a different manufacturing flow. > As a result we need both leaded and lead-free ordering codes for most > devices and most of these lead-free ordering codes have been in place > for several quarters. > > You can find a complete listing of Altera's lead-free solutions at > http://www.altera.com/products/devices/leadfree/lead-free_index.html > > > Dave Greenfield > Altera Marketing > > >>Today I got this in Altera's email newsletter > >>Get RoHS Compliant with Altera FPGAs, CPLDs and Structured ASICs > > >>I have never seen a single 3000 series PLD available in leadfree that you >>could actually purchase for delivery from stock. I have been able to buy >>lead versions of most of this family without too much trouble. . . . > > Thanks for responding Dave. I asked Arrow to place lead free parts from Altera in a bond. They came back and told us these were "GS", guaranteed stock. At the time, which was only a few months ago, they had lots of lead parts and no lead free parts in the 3000 family. Arrow now shows very long lead times for all versions. Max II parts are on allocation and I can't get these placed in my bond, but I managed to buy a small quantity. DigiKey, another Altera distributor shows only lead versions and treats lead free versions as Non-Stock items. My guess is that they didn't want to sell both types and wanted to make sure that they had gotten rid of all the lead inventory first. In my view, very few customers are going to want to stop selling to the EU. I realize that there are exceptions to the mandates and that some customers really don't care. Generally a lead free part works just fine with a lead solder process (except BGAs since the profile needs to be different). My rant started because as a supplier of single source parts, you need to insure reasonable deliveries. At the moment, you aren't promising parts before June. At the same time, your promotional material is bragging that you are committed to RoHS parts that have never been readily available to my knowledge. Maybe you just underestimated the demand, problems in the distribution channel or difficulties with process changes. I know that Altera is not alone with this problem, its the irony of the ad that set me off.... -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.comArticle: 97017
Partial reconfig for V4 requires additional software that is not included in 8.1i. PlanAhead is also required. You need to contact your local FAE to gain access to this software. Steve Symon wrote: > Hi xun, > Check out Xilinx's PlanAhead product. Quote:- > "New Partial Reconfiguration features and capabilities in PlanAhead 8.1 > simplify the implementation of this complex but powerful design flow. > Combined with the ISE 8.1i Design Tools, PlanAhead 8.1 delivers the > industry's only front-to-back solution for partial reconfiguration." > www.xilinx.com/planahead > Make sure you report back to let us know how you're getting along! > Good luck (you'll need it!) Syms. > > <zhangxun0501@gmail.com> wrote in message > news:1139929097.244112.281090@g44g2000cwa.googlegroups.com... > >>I just begining my work on dynamic partial reconfiguration of Xilinx >>Virtex-4 FPGAs. I have readed those article sur the site of Xilinx >>e.g; the guild of configuration , use guid etc. but I havent also any >>idea for the begining. I wish someone can give me a real exemple or >>some advices for the dynamic partial reconfiguration of Virtex-4. >> >>thanks on advance, >> >>xun >> > > >Article: 97018
Al Clark wrote: > DigiKey, another Altera distributor shows only lead versions and treats > lead free versions as Non-Stock items. My guess is that they didn't want to > sell both types and wanted to make sure that they had gotten rid of all the > lead inventory first. I don't think you are going to see leaded parts going away just because the EU requires lead free parts. I work for a company that gets a lot of attention from distributors and manufacturers and they have assured us that lead based parts will be around for a long time. There are just too many designs that are not going to change even if they can't be sold in the EU. > In my view, very few customers are going to want to stop selling to the EU. > I realize that there are exceptions to the mandates and that some customers > really don't care. Generally a lead free part works just fine with a lead > solder process (except BGAs since the profile needs to be different). In general, not many are interested in taking chances with their process. There is no shortage of lead parts and there are lots of customers outside the EU. Although many will want to convert their manufacturing right away, there are many who don't want to be on the bleeding edge. They will wait out the transition and adopt the new processes only after they are fully proven. One thing I keep hearing about is how the lead free solder is brittle. I don't know if this is true, but mechanical failure is just as bad and electrical failure of a part. > My rant started because as a supplier of single source parts, you need to > insure reasonable deliveries. At the moment, you aren't promising parts > before June. At the same time, your promotional material is bragging that > you are committed to RoHS parts that have never been readily available to > my knowledge. Maybe you just underestimated the demand, problems in the > distribution channel or difficulties with process changes. I know that > Altera is not alone with this problem, its the irony of the ad that set me > off....Article: 97019
Jan Panteltje wrote: > On a sunny day (Mon, 13 Feb 2006 16:29:50 -0800) it happened Mike Treseler > <mike_treseler@comcast.net> wrote in <45cmk0F64n8sU1@individual.net>: > >>Yes. Even some of the newer generation >>seem convinced that FPGAs are full of >>little counters, shifters > > whots wrong with SLRs? No parallel port?Article: 97020
sir i wrote codings for capacitive sensor while compiling i got a fatal error like Fatal: (vsim-3421) Value 1.#INF is out of range 1e+308 to -1e+308. # Time: 0 ns Iteration: 1 Process: /capasens_calc/line__137 File: C:/FPGAdv61/Modeltech/casens sir how can i overcome this also i got the error in this line fvoltage0:=(fcharge/fparacap1)*((a-fgamma)/fp); this is my coding library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; -- Uncomment the following lines to use the declarations that are -- provided for instantiating Xilinx primitive components. --library UNISIM; --use UNISIM.VComponents.all; entity capasens_calc is port(area: in real; dist:in real; charge:in real; paracap:in real; capacitance:inout real; gamma:in real; paracap1:in real; p:inout real; alpha:in integer; Vcharge: in real; Vthreshold:in real; gm:in real; voltage0:inout real; capaload:in real; Ts:inout real; voltage:out real; voltage1: out real; output:out bit); end capasens_calc; architecture behavioral of capasens_calc is signal p1:real; signal p2:integer; function capa_calc(signal farea:real;fdist:real) return real is constant Eo : real:=8.159; variable fcapacitance : real; begin fcapacitance:=(Eo*farea/fdist); return fcapacitance; end capa_calc; function volt_calc(signal fcharge:real;fcapacitance:real;fparacap:real) return real is variable fvoltage:real; begin fvoltage:=(fcharge/(fcapacitance+fparacap)); return fvoltage; end volt_calc; function saout_calc(signal fcharge:real;fparacap:real) return real is variable fvoltage1: real; begin fvoltage1:=(fcharge/fparacap); return fvoltage1; end saout_calc; function p1_calc(signal fcapacitance:real;fparacap:real) return real is variable fp1:real; constant a :real:=1.0; begin fp1:=(a+(fcapacitance/fparacap)); return fp1; end p1_calc; function p2_calc(signal falpha:integer) return integer is variable fp2:integer; constant a :integer:=1; begin fp2:=(falpha+a); return fp2; end p2_calc; function p_calc(signal fp1:real;fp2:integer) return real is variable fp:real; begin fp:=fp1**fp2; return fp; end p_calc; function charge_calc(signal fp:real;fgamma:real;fcharge:real;fparacap1:real) return real is variable fvoltage0:real; constant a :real:=1.0; begin fvoltage0:=(fcharge/fparacap1)*((a-fgamma)/fp); return fvoltage0; end charge_calc; function schtrigger(signal fVcharge:real;fVthreshold:real;fgm:real;fvoltage0:real) return real is variable fTs:real; begin if(fVcharge>fVthreshold)then fTs:=(fVcharge*fVthreshold)/(fgm*fvoltage0); return fTs; else fTs:=0.0; return fTs; end if; end schtrigger; function capasens_calc(signal fcapaload:real;fTs:in real) return bit is variable foutput:bit; begin if(fcapaload >=5.0) and (fTs <=5.0)then foutput:='1'; return foutput; else foutput:='0'; return foutput; end if; end capasens_calc; begin capacitance<=capa_calc(area,dist); voltage<=volt_calc(charge,capacitance,paracap); voltage1<=saout_calc(charge,paracap); p1<=p1_calc(capacitance,paracap); p2<=p2_calc(alpha); p<=p_calc(p1,p2); voltage0<=charge_calc(p,gamma,charge,paracap1); Ts<=Schtrigger(Vcharge,Vthreshold,gm,voltage0); output<=capasens_calc(capaload,Ts); end behavioral;Article: 97021
rickman wrote: > Al Clark wrote: > >>DigiKey, another Altera distributor shows only lead versions and treats >>lead free versions as Non-Stock items. My guess is that they didn't want to >>sell both types and wanted to make sure that they had gotten rid of all the >>lead inventory first. > > > I don't think you are going to see leaded parts going away just because > the EU requires lead free parts. I work for a company that gets a lot > of attention from distributors and manufacturers and they have assured > us that lead based parts will be around for a long time. There are > just too many designs that are not going to change even if they can't > be sold in the EU. Can you clarify which ones actually _have_ lead, as opposed to not being RoHS complaint ( which includes other materials too ). ie I thought that gull wing packages like TQFP and PQFP, as well as MLF packages, resistors, caps, are already tin or nickel plated, and have been for a while ? BGA packages, I CAN understand, as they use Solder Balls, so those you would want to match to your paste... -jgArticle: 97022
Jim Granville wrote: > rickman wrote: > > Al Clark wrote: > > > >>DigiKey, another Altera distributor shows only lead versions and treats > >>lead free versions as Non-Stock items. My guess is that they didn't want to > >>sell both types and wanted to make sure that they had gotten rid of all the > >>lead inventory first. > > > > > > I don't think you are going to see leaded parts going away just because > > the EU requires lead free parts. I work for a company that gets a lot > > of attention from distributors and manufacturers and they have assured > > us that lead based parts will be around for a long time. There are > > just too many designs that are not going to change even if they can't > > be sold in the EU. > > Can you clarify which ones actually _have_ lead, as opposed to > not being RoHS complaint ( which includes other materials too ). The RoHS rules have holes large enough to drive the entire EU parliament through (while drinking) One notable 'exempt' industry is automotive, so expect the automotive parts to not necessarily change - indeed TI has separated it's automotive catalog from it's other offerings already. As automotive accounts for a rather large percentage of small electronics devices, that exemption alone renders most of RoHS farcical. If the intent is to protect consumers, then perhaps it's a good idea, but the fact of the matter is it is more expensive to manufacture completely RoHS boards (I know, I design them and get the quotes from contract manufacturers). The consumer market being what it is, it will mean either a lower profit margin (the consumer market is notoriously price sensitive) or products simply not being offered on consumer scales. Just my take Cheers PeteS > > ie I thought that gull wing packages like TQFP and PQFP, as > well as MLF packages, resistors, caps, > are already tin or nickel plated, and have been for a while ? > > BGA packages, I CAN understand, as they use Solder Balls, > so those you would want to match to your paste... > > -jgArticle: 97023
This is a multi-part message in MIME format.
------=_NextPart_000_0013_01C63245.533E93A0
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: quoted-printable
Hi, Dears:
I am using QuartusII now. I am not clear to back-annotate. What is =
back_annotate? and what's the use of back-annotate?=20
Thank you!
Jude
------=_NextPart_000_0013_01C63245.533E93A0
Content-Type: text/html;
charset="gb2312"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D=CB=CE=CC=E5 size=3D2>
<DIV><FONT face=3D=CB=CE=CC=E5 size=3D2>Hi, Dears:</FONT></DIV>
<DIV><FONT face=3D=CB=CE=CC=E5 size=3D2> I am =
using QuartusII now. I am=20
not clear to back-annotate. What is back_annotate? and what's the use of =
back-annotate? </FONT></DIV>
<DIV><FONT face=3D=CB=CE=CC=E5 size=3D2>Thank you!</FONT></DIV>
<DIV><FONT face=3D=CB=CE=CC=E5 size=3D2></FONT> </DIV>
<DIV><FONT face=3D=CB=CE=CC=E5 =
size=3D2>Jude</FONT></DIV></FONT></DIV></BODY></HTML>
------=_NextPart_000_0013_01C63245.533E93A0--
Article: 97024>I like your approach, but I think you really have to start with a >top-level block diagram that describes how you intend to solve the >overall problem. Then you solve it in chunks, from the bottom up... >I think age and experience strongly influences these choices... The software guys have been having religious wars over top-down vs bottom-up ever since I first enountered either term. My vote is to work on the hard part. If you think you understand the overall data flow but aren't sure how to make some chunk go fast enough, then start working on that "bottom" level chunk. If all the bottom chunks look easy, then make sure you understand the high level. The truly amazing performance gains are usually the result of algorithim changes. Consider FFT vs the old slow way. Consider hashing vs searching a long list. On the other hand, lots of times, a factor of 2 in some low level chunk can make or break a project. Is counting IO pins, CLBs, BRAMs or ... top or bottom? -- 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.
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