Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 157000

Article: 157000
Subject: ZPU-based SoC for Numato Saturn board with DRAM
From: "mnentwig" <24789@embeddedrelated>
Date: Mon, 18 Aug 2014 10:11:21 -0500
Links: << >>  << T >>  << A >>
Hi,

this is a "public backup" of a holiday project maybe it's of use to
someone:
https://drive.google.com/file/d/0B1gLUU8hXL7veXVmZDhURGJ0N3c/edit?usp=sharing

- "medium" ZPU processor
- instantiated BRAM and upload of program code via DATA2MEM. Re-compiling
the C-code and uploading a new bitstream takes about three seconds, which
isn't too bad (I use Xilinx' platform cable USB; the Saturn V3 should also
support xc3sprog upload by itself)
- basic LPDRAM access as "proof-of-concept" using the Xilinx DRAM
controller 
- basic VGA, connect with Dupont wires to an analog RGB monitor input
- timing is met at the default 100 MHz clock
- address decoder with support for zero-waitstate reads (i.e. from hardware
registers)
- performance is almost 1M 32-bit read/writes from DRAM per second, three
times faster in internal BRAM. A speed demon in slow motion...
- 9 % slice utilization (6 % LUT) on Spartan 6 LX45	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157001
Subject: calculations of logic vectors and constant
From: "itay" <101236@embeddedrelated>
Date: Mon, 18 Aug 2014 12:02:10 -0500
Links: << >>  << T >>  << A >>
what is the prefered option of arithmetic operations using  logic vectors
and constant? convert logic vector to integer and do the operation or to
convert the constant to logic vector?

I have samples from A/D as logic vectors with some resolution and
constants. I want to do arithmetic operations between them according to
formula?
if anyone has examples of such thing it will be very helpfull (VHDL).

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157002
Subject: Re: calculations of logic vectors and constant
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Mon, 18 Aug 2014 10:27:48 -0700
Links: << >>  << T >>  << A >>
On Mon, 18 Aug 2014 12:02:10 -0500
"itay" <101236@embeddedrelated> wrote:

> what is the prefered option of arithmetic operations using  logic vectors
> and constant? convert logic vector to integer and do the operation or to
> convert the constant to logic vector?
> 
> I have samples from A/D as logic vectors with some resolution and
> constants. I want to do arithmetic operations between them according to
> formula?
> if anyone has examples of such thing it will be very helpfull (VHDL).
> 
> 	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

std_logic_vectors don't do math.  They only hold bits.  If they're
doing math, you're using some library that you shouldn't be, like
std_logic_arith.

Unsigned/signed do in fact do math, and typecast from
std_logic_vector.  You'll find them in numeric_std.  They're useful for
doing math when you:
  a) Need to be concerned about non-binary values such as 'X' and '-'
  b) Specifically want the overflow rollover behavior on add/subtract
  c) Have to deal with numbers outside the range +/-(2**31 - 1)

Integers are fundamentally better than unsigned/signed in simulation.
They're faster, you can ascribe specific bounds to them, and when you're
working with them they need less syntax (as opposed to getting in and
out of them, which is a whole other story).  I prefer to use integers
where possible, and fall back to signed/unsigned for the above reasons
when I have to.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 157003
Subject: Re: calculations of logic vectors and constant
From: jonesandy@comcast.net
Date: Thu, 21 Aug 2014 18:44:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, August 18, 2014 12:27:48 PM UTC-5, Rob Gaddi wrote:
> std_logic_vectors don't do math. They only hold bits. If they're doing ma=
th, you're using some library that you shouldn't be, like std_logic_arith.=
=20

As of the 2008 standard, the ieee.numeric_std_unsigned package extends arit=
hmetic and relational operators, with an unsigned interpretation, to std_lo=
gic_vector. It also contains conversion functions for natural/std_logic_vec=
tor.

If you need signed arithmetic, then you need to use either numeric_std.sign=
ed. You can also use the ieee fixed point packages (sfixed type), with zero=
 or more fractional bits. sfixed has the benefit of automatically expanding=
 the result range/precision to handle the maximum/minimum arithmetic result=
, and can be configured for saturation and rounding logic on resize.=20

As for the use of integer or signed constants, my preference when defining =
a numerical value is to use integer if within integer'range. If using sfixe=
d, then real constants are useful. Real/integer values can be added to sfix=
ed/signed quantities automatically (the scalar operand is converted to sign=
ed/sfixed of same range/precision as the vector operand).

2008 also provides a floating point library in 2008, with configurably size=
d mantissa and exponent.

Andy

Article: 157004
Subject: xc3sprog "instruction capture is 0x3f" (solved)
From: "mnentwig" <24789@embeddedrelated>
Date: Sat, 23 Aug 2014 06:00:56 -0500
Links: << >>  << T >>  << A >>
Hi,

if anybody else runs into the same problem with an FPGA module:

xc3sprog failed to upload the bitstream to a Spartan 6 LX45, complaining
"instruction capture is 0x3f".
The JTAG chain itself was recognized, it reported the device correctly.

The cause was insufficient 3.3 V supply voltage on the FPGA board, measured
at around 3.08 V.
Some modification to the LM1117 adjustment resistors brought it back up to
3.3 V and the board works again. 

Don't know if all variants of this regulator have overcurrent protection,
maybe it was damaged by earlier abuse.



	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157005
Subject: Re: xc3sprog
From: "mnentwig" <24789@embeddedrelated>
Date: Sat, 23 Aug 2014 06:22:42 -0500
Links: << >>  << T >>  << A >>
>> (solved) 
or not.
The problem re-appeared, probably the board is broken.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157006
Subject: Re: xc3sprog
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Sat, 23 Aug 2014 15:15:18 +0000 (UTC)
Links: << >>  << T >>  << A >>
mnentwig <24789@embeddedrelated> wrote:
> >> (solved) 
> or not.
> The problem re-appeared, probably the board is broken.     

Please let me know if the problem comes out as not hardware related.

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 157007
Subject: Bidirectional Pin FPGA (Parallel ADC)
From: osodipe@eng.ucsd.edu
Date: Mon, 25 Aug 2014 06:18:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hey guys(and gals)

FPGA convert here trying to use bidirectional pins on an Altera Board within a data acquisition project. What are the ways to implement such a design in VHDL or Verilog? Thanks!

Olu

Article: 157008
Subject: Re: Bidirectional Pin FPGA (Parallel ADC)
From: "Andy Bartlett" <abartlett@nospam.net>
Date: Mon, 25 Aug 2014 16:52:54 +0100
Links: << >>  << T >>  << A >>

<osodipe@eng.ucsd.edu> wrote in message 
news:5f2f4946-2e38-4875-9e0e-e27c70128514@googlegroups.com...
> Hey guys(and gals)
>
> FPGA convert here trying to use bidirectional pins on an Altera Board 
> within a data acquisition project. What are the ways to implement such a 
> design in VHDL or Verilog? Thanks!
>
> Olu


Declare the pin as bidirectional.
Drive the pin with a tristate driver.
Ignore data coming in to the pin while the tristate is enabled.

Andy 



Article: 157009
Subject: Re: Bidirectional Pin FPGA (Parallel ADC)
From: osodipe@eng.ucsd.edu
Date: Mon, 25 Aug 2014 10:57:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, August 25, 2014 9:18:59 AM UTC-4, oso...@eng.ucsd.edu wrote:
> Hey guys(and gals) FPGA convert here trying to use bidirectional pins on =
an Altera Board within a data acquisition project. What are the ways to imp=
lement such a design in VHDL or Verilog? Thanks! Olu

Thanks, guys. I have actually been going the tri-state route with not much =
success and I was hoping there was a different way to implement bidirection=
al signals on an FPGA. To clarify further, my HDL simulates fine but my syn=
thesis leaves much to be desired. I have disparate write and read cycles co=
ntrolled by an FSM but for some reason, whatever I write into the ADC durin=
g the write cycle is being "echoed back" to me during my read(to read ADC d=
ata) cycle. Here is my current Verilog code

    inout 	[11:0] 	 adc_data_pin_top,
    assign adc_data_pin_top  =3D ~write_adc_data ? written_data_temp : 12'b=
z;
    assign data_from_adc =3D converted_datas;

    always @ (posedge adc_clock)
    begin
       converted_datas <=3D adc_data_pin_top;
       written_data_temp <=3D written_data_adc;
    end

Article: 157010
Subject: Re: Bidirectional Pin FPGA (Parallel ADC)
From: rickman <gnuarm@gmail.com>
Date: Mon, 25 Aug 2014 16:32:49 -0400
Links: << >>  << T >>  << A >>
On 8/25/2014 1:57 PM, osodipe@eng.ucsd.edu wrote:
> On Monday, August 25, 2014 9:18:59 AM UTC-4, oso...@eng.ucsd.edu wrote:
>> Hey guys(and gals) FPGA convert here trying to use bidirectional pins on an Altera Board within a data acquisition project. What are the ways to implement such a design in VHDL or Verilog? Thanks! Olu
>
> Thanks, guys. I have actually been going the tri-state route with not much success and I was hoping there was a different way to implement bidirectional signals on an FPGA. To clarify further, my HDL simulates fine but my synthesis leaves much to be desired. I have disparate write and read cycles controlled by an FSM but for some reason, whatever I write into the ADC during the write cycle is being "echoed back" to me during my read(to read ADC data) cycle. Here is my current Verilog code
>
>      inout 	[11:0] 	 adc_data_pin_top,
>      assign adc_data_pin_top  = ~write_adc_data ? written_data_temp : 12'bz;
>      assign data_from_adc = converted_datas;
>
>      always @ (posedge adc_clock)
>      begin
>         converted_datas <= adc_data_pin_top;
>         written_data_temp <= written_data_adc;
>      end

What is controlling the signal write_adc_data?  That signal should be 
low when writing data and high when reading.  What is driving the signal 
written_data_adc?  Do you really need to register it?

Can you explain why the ADC bus needs to be written?  Is there setup 
data that needs to be sent to it or are you talking to another device 
like a DAC?

-- 

Rick

Article: 157011
Subject: Re: Bidirectional Pin FPGA (Parallel ADC)
From: osodipe@eng.ucsd.edu
Date: Tue, 26 Aug 2014 04:50:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hey Rick,

Thanks for your response. The write_adc_data is a low enable signal generat=
ed by a Finite State Machine and yes, it is low when writing and high the r=
est of the time. My read requires an additional enable, though. You are pro=
bably right about the need to register the separate input/output signals--t=
he IO cell has an inbuilt register I was trying to use, but there is a line=
 that bypasses that(meaning I could probably get away with a continuous ass=
ignment statement). How does the register/no register impact my design besi=
des timing?


On Monday, August 25, 2014 4:32:49 PM UTC-4, rickman wrote:
> On 8/25/2014 1:57 PM,  wrote: > On Monday, August 25, 2014 9:18:59 AM UTC=
-4, wrote: >> Hey guys(and gals) FPGA convert here trying to use bidirectio=
nal pins on an Altera Board within a data acquisition project. What are the=
 ways to implement such a design in VHDL or Verilog? Thanks! Olu > > Thanks=
, guys. I have actually been going the tri-state route with not much succes=
s and I was hoping there was a different way to implement bidirectional sig=
nals on an FPGA. To clarify further, my HDL simulates fine but my synthesis=
 leaves much to be desired. I have disparate write and read cycles controll=
ed by an FSM but for some reason, whatever I write into the ADC during the =
write cycle is being "echoed back" to me during my read(to read ADC data) c=
ycle. Here is my current Verilog code > > inout [11:0] adc_data_pin_top, > =
assign adc_data_pin_top =3D ~write_adc_data ? written_data_temp : 12'bz; > =
assign data_from_adc =3D converted_datas; > > always @ (posedge adc_clock) =
> begin > converted_datas <=3D adc_data_pin_top; > written_data_temp <=3D w=
ritten_data_adc; > end What is controlling the signal write_adc_data? That =
signal should be low when writing data and high when reading. What is drivi=
ng the signal written_data_adc? Do you really need to register it? Can you =
explain why the ADC bus needs to be written? Is there setup data that needs=
 to be sent to it or are you talking to another device like a DAC? -- Rick


Article: 157012
Subject: Re: Bidirectional Pin FPGA (Parallel ADC)
From: Aleksandar Kuktin <akuktin@gmail.com>
Date: Tue, 26 Aug 2014 14:18:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Mon, 25 Aug 2014 10:57:47 -0700, osodipe wrote:

> assign adc_data_pin_top  = ~write_adc_data ? written_data_temp : 12'bz;

And if you change this to 12'bzzzzzzzzzzzz ? I had problems of that sort 
once.

Article: 157013
Subject: Re: Bidirectional Pin FPGA (Parallel ADC)
From: Daniel Kho <daniel.kho@gmail.com>
Date: Tue, 26 Aug 2014 13:05:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
Before reading from a bidirectional pin, make sure you "release" the pin to tristate first. Similarly, wait for the peripheral (connected to your FPGA) to be ready to read your data, before driving the pin to any deterministic value ('0' or '1').

E.g.:

entity bidir is port(adc_data_pin_top: inout std_ulogic_vector(11 downto 0));
end entity bidir;

architecture rtl of bidir is
    signal write_adc_data: boolean;   -- flag to enable writing.
begin
    adc_data_pin_top <= written_data_temp when write_adc_data else (others=>'Z');

    process(adc_clock) is begin
        if rising_edge(adc_clock) then
            converted_datas <= adc_data_pin_top when not write_adc_data;    -- use if-else if your tool doesn't yet support this.
            written_data_temp <= written_data_adc;
        end if;
    end process;
end architecture rtl;

It's better to have both the write and read as synchronous clocked processes though.

-dan

Article: 157014
Subject: Re: Bidirectional Pin FPGA (Parallel ADC)
From: Daniel Kho <daniel.kho@gmail.com>
Date: Tue, 26 Aug 2014 13:14:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, 27 August 2014 04:05:38 UTC+8, Daniel Kho  wrote:

>     adc_data_pin_top <= written_data_temp when write_adc_data else (others=>'Z');
> 

Here, the slave's readiness to read data from your FPGA may be used to determine the value of write_adc_data.


>             converted_datas <= adc_data_pin_top when not write_adc_data;    -- use if-else if your tool doesn't yet support this.
> 

Save the data only when the line has already been released to (others=>'Z') by the driver process, and the slave is sending data. You may add additional checks here.

Article: 157015
Subject: Re: Bidirectional Pin FPGA (Parallel ADC)
From: gtwrek@sonic.net (Mark Curry)
Date: Tue, 26 Aug 2014 21:56:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <lti4vv$984$2@speranza.aioe.org>,
Aleksandar Kuktin  <akuktin@gmail.com> wrote:
>On Mon, 25 Aug 2014 10:57:47 -0700, osodipe wrote:
>
>> assign adc_data_pin_top  = ~write_adc_data ? written_data_temp : 12'bz;
>
>And if you change this to 12'bzzzzzzzzzzzz ? I had problems of that sort 
>once.

This.

I'm fairly certain that the code the OP originally wrote would assign 
adc_data_pin_top to 12'b0000_0000_000z when write_adc_data == 1.  Instead
of the desired all tri-state.  Later versions of verilog (2001, or maybe it's 
systemverilog, I don't recall) had some kind of syntactic sugar that's 
interpreted as "z-extend" the top bits (instead of the default 0 fill).

Instead of the long string of Z's I use the verilog replication operator i.e.

assign adc_data_pin_top  = ( ~write_adc_data ) ? written_data_temp : { 12 { 1'bz } };

Regards,

Mark 





Article: 157016
Subject: Re: How to reduce "Core static thermal dissipation" from fpga design
From: prince.kiran@gmail.com
Date: Wed, 27 Aug 2014 09:32:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Pedro,

I am sorry i don't have solution for your problem, but can you please tell me how did you get
Power Estimation Confidence     High: user provided sufficient toggle rate data 
in your report, i always get
Power Estimation Confidence     Low: user provided insufficient toggle rate data
in my report, can you tell me how do i provide sufficient toggle rate data.

Thank You
Kiran Prince

Article: 157017
Subject: wrong waveforms in vivado waveform viewer
From: langwadt@fonz.dk
Date: Thu, 28 Aug 2014 08:19:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
Has anyone experience the Vivado waveform viewer just making up waveforms? 

I have a module with two different signals, lets say x and y

if I go down the hierarchy and add them to the waveform view they show up as identical and the waveform shown looks like an OR of the expected values. 

If I add the two signals as outputs to the module and connect them to wires 
a level up and add those two the waveform those waveforms are correct

what's going on?

-Lasse

Article: 157018
Subject: Re: wrong waveforms in vivado waveform viewer
From: "mnentwig" <24789@embeddedrelated>
Date: Fri, 29 Aug 2014 08:37:29 -0500
Links: << >>  << T >>  << A >>
Hi,

I can't comment on that but maybe "gtkwave" is an interesting alternative.

It's very popular. 
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157019
Subject: xc3sprog: SPI flash access for Spartan 6 LX 25 TFQ256 (Xess Xula 2)
From: "mnentwig" <24789@embeddedrelated>
Date: Fri, 29 Aug 2014 11:50:23 -0500
Links: << >>  << T >>  << A >>
Hi,

I wasn't able to find a bscan .bit file to program the flash on my Xula2
board so I built it myself. 
Link follows, includes also the .ucf file (only LOCs for the flash pins,
nothing else).

It requires an external JTAG interface and a Xula2 board needs to be
configured for external JTAG (see manual). In other words, it will -not-
work through the USB connector on the board. The vendor's tool will do that
(but I didn't succeed in running it on Windows 8.1).

Use at your own risk.

https://drive.google.com/file/d/0B1gLUU8hXL7vakJyV2c4SXplRTQ/edit?usp=sharing	
  
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157020
Subject: Functional safety guidelines
From: "Tomas D." <mailsoc@gmial.com>
Date: Sun, 31 Aug 2014 23:15:43 +0100
Links: << >>  << T >>  << A >>
Hello,
I wonder maybe someone have automotive functional safety guidelines for VHDL 
and is willing to share?
I think there's a package available from Altera, however they charge 10k for 
it telling that it is a small fee.

Thank you. 



Article: 157021
Subject: Re: Functional safety guidelines
From: Tobias Baumann <ttobsen@hotmail.com>
Date: Mon, 01 Sep 2014 12:35:03 +0200
Links: << >>  << T >>  << A >>
Am 01.09.2014 um 00:15 schrieb Tomas D.:
> Hello,
> I wonder maybe someone have automotive functional safety guidelines for VHDL
> and is willing to share?
> I think there's a package available from Altera, however they charge 10k for
> it telling that it is a small fee.
>
> Thank you.
>
>

Hi,

maybe this one is something for you:

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5712336&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5712336

It's not specially for automotive and not very informative, but maybe a 
first idea.

Best regards,
Tobias

Article: 157022
Subject: Re: Functional safety guidelines
From: Rob Doyle <radioengr@gmail.com>
Date: Mon, 01 Sep 2014 11:43:50 -0700
Links: << >>  << T >>  << A >>
On 8/31/2014 3:15 PM, Tomas D. wrote:
> Hello,
> I wonder maybe someone have automotive functional safety guidelines for VHDL
> and is willing to share?
> I think there's a package available from Altera, however they charge 10k for
> it telling that it is a small fee.
>
> Thank you.
>

It's not automotive - but the aerospace industry uses RTCA DO-254.

http://en.wikipedia.org/wiki/DO-254

Rob.



Article: 157023
Subject: Re: Easy PC software tool - Bad experience
From: quarrie92@googlemail.com
Date: Tue, 2 Sep 2014 18:42:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, 19 January 2010 11:29:56 UTC, Roger  wrote:
> Due to a bug in the Easy PC software tool from Numberone Systems, I've ju=
st=20
> had a very time consuming and costly incident....

I just sent off a last minute design to China with NO copper pour (deadline=
s mean I just had to fatten tracks and try to ignore CE TCFs etc). Worked f=
ine on earlier version of the board but .. no go on this one. Forums full o=
f similar complaints, but no solution.=20

In addition, I must be one of their 1st customers, and over the years I've =
spent way more than 1K on it, so Colin, don't go preaching the You get what=
 you Pay For line :-).=20

However, I am also a software developer and I have sympathy for No1. What w=
ould be a good-will gesture that doesn't seriously hit their bottom line?=
=20

The difficulty is getting paid without doing endless updates, and with endl=
ess updates comes change, and .. it sure ain't "Easy" PC anymore. There mus=
t be something easier out there. The Help on it does my head in (I can see =
they've tried, but when you are sitting there thinking .. how do I do that?=
 Don't bother looking at help!).=20

Summary: They could do with a clear out. Copper Pour needs a re-write. The =
rest needs simplifying, as after all it was never a tool for corporate need=
s, but it was a good tool for serious professional with low volume requirem=
ents. They have my continued support. Just.

Article: 157024
Subject: Re: Easy PC software tool - Bad experience
From: MK <mk@nospam.co.uk>
Date: Wed, 03 Sep 2014 10:05:18 +0100
Links: << >>  << T >>  << A >>
On 03/09/2014 02:42, quarrie92@googlemail.com wrote:
> On Tuesday, 19 January 2010 11:29:56 UTC, Roger  wrote:
>> Due to a bug in the Easy PC software tool from Numberone Systems, I've just
>> had a very time consuming and costly incident....
>
> I just sent off a last minute design to China with NO copper pour (deadlines mean I just had to fatten tracks and try to ignore CE TCFs etc). Worked fine on earlier version of the board but .. no go on this one. Forums full of similar complaints, but no solution.
>
> In addition, I must be one of their 1st customers, and over the years I've spent way more than 1K on it, so Colin, don't go preaching the You get what you Pay For line :-).
>
> However, I am also a software developer and I have sympathy for No1. What would be a good-will gesture that doesn't seriously hit their bottom line?
>
> The difficulty is getting paid without doing endless updates, and with endless updates comes change, and .. it sure ain't "Easy" PC anymore. There must be something easier out there. The Help on it does my head in (I can see they've tried, but when you are sitting there thinking .. how do I do that? Don't bother looking at help!).
>
> Summary: They could do with a clear out. Copper Pour needs a re-write. The rest needs simplifying, as after all it was never a tool for corporate needs, but it was a good tool for serious professional with low volume requirements. They have my continued support. Just.
>
Not quite sure why you are posting this as  a response to a 4 year old 
post but I'm assuming that your comment is current.
I'm a long term user of EasyPC and I don't agree with most of your 
comments at all. It still is a very simple and low cost tool. And 
although the copper pour still has issues the general reliability of the 
product is much better than the much more expensive PCB cad tools I've used.
The Help, as with anything , could be better but it's not bad.

(BTW - if you get stuck with a copper pour problem then reduce the pour 
area until you locate the offending item that it won't pour round - this 
will usually get you out of immediate trouble. And do tell No1 about the 
problem - they do fix stuff.)

Michael Kellett





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search