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
Frank wrote: ... > Now I set NFS/GAIN = 0 on datasheet it says "offset binary output available, > 1 V p-p supported;". > and ADC input is -20mV ~ 0.8V, what range of digital values do I get after > ADC? What does that > offset mean here? > > Is this interpretation correct? > 0 for -20mV, > 0xCCC for 0.8V? Why 0xCCC? for 12 bits, you should get 0xFFF. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 92401
Hi, I just got chosen as 'project manager' for our next project. It seems like most people feel 'sorry' for me around here... We are designing a moderately large mostly digital asic and the team consists of about 6 people. I've never managed anything before and most of the people in the team are more senior designer than me. Right now, things are decided from hallway conversations, and nothing is really written down in terms of schedule and who-does-what... I wonder what tools if any that people use to manage a project. Is something like MS-Project any good? I understand that the schedule we would put in place will never hold, but I figure it's better to have something than nothing. Also, what do people use to track down bugs and issues. The chip is divided in 6-7 blocks, each will be assigned to one-two person. Where should I gather the information coming out of the weekly meeting - schedule slip, bugs to be fixed etc...email? ms-project? hallway? Thanks a lot, DaveArticle: 92402
Fred wrote: > Have a problem so tracing signals. What's a X_LUT3? A standard LUT3 only > has an INIT value of 0 to 7. This is the "...translate.vhd" file which has > this primitive and an INIT value of x"EB". > > Q_n0024_0_1 : X_LUT3 > generic map( > INIT => X"EB" > ) > port map ( > ADR0 => cycle(2), > ADR1 => cycle(0), > ADR2 => cycle(1), > O => Q_n0024(0) > ); All of the X_* components are simprim primitives. You can find out what it is by looking at the file simprim_VITAL.vhd.Article: 92403
"damir" <damir.makni@srce.hr> wrote in message news:dmhkkh$k2a$1@bagan.srce.hr... > Just to add small clarification - > > What happens is that output FIFO on FX2 is not emptied on time by PC host > (using USB BULK IN transfers) - this results that internal FX2 FIFO gets > full for significant amount of time and we are currently not able to > compensate this using small FIFO implemented in FPGA. > > As the bandwidth we are using is only a fraction of bandwidth provided by > USB 2.0, I'm suspicious about driver performance. > > Damir > > "damir" <damir.makni@srce.hr> wrote in message > news:dmhhe6$ej8$1@bagan.srce.hr... > > We have developed data acquisition system which uses Cypress FX2 as the > > USB 2.0 interface. State machine for control and conversion of data > > between AD converters and FX2 is implemented using Xilinx Spartan 2 FPGA. > > The problem is that with higher data rates (up to 25 Mbit/s) we experience > > FX2 internal FIFO stalls and missing data on the receiving side. Small > > FIFO implemented inside FPGA does not help to resolve the problem. On the > > PC, data acquisition is implemented using CyAPI & CyUSB. USB bulk mode is > > used for transfer. > > > > As mentioned data rate is only a fraction of USB 2.0 bandwidth, I don't > > know if the mentioned problem is related to the implementation of the > > receiver side (CyAPI) or lacking capability to sustain such bandwidth > > within Cypress FX2. > > > > Did anyone have similar problems using FX2 and how you manage to solve it? > > > > I will appreciate any help to resolve this problem, if possible in > > software - hardware solution will require redesign of the PCB and > > implementation/addition of large size FIFO to buffer FX2 stalls (which > > may, according to our experience, extend up to 50 ms). > > > > Thanks, > > > > Damir > > > > > > > > Hello, I think your problem is a combination of the PC OS (Windows ?) and bulk transfer mode. On a system I designed using the Cypress FX and USB1.1 we were able to get average data rates up to 800k bytes/s (yes bytes/s) but needed a 40 kbyte buffer to cope with 'stalls'. Interestingly that's about the same as the 50mS you are seeing. If you don't write your driver properly you can make it a lot worse but we never got it much better. Michael Kellett www.mkesc.co.ukArticle: 92404
snip snip
>
> I think your problem is a combination of the PC OS (Windows ?) and bulk
> transfer mode. On a system I designed using the Cypress FX and USB1.1 we
> were able to get average data rates up to 800k bytes/s (yes bytes/s) but
> needed a 40 kbyte buffer to cope with 'stalls'. Interestingly that's about
> the same as the 50mS you are seeing. If you don't write your driver
> properly
> you can make it a lot worse but we never got it much better.
>
> Michael Kellett
>
> www.mkesc.co.uk
>
>
We needed 4 MBytes/sec Out (the OP was In) and saw that XP could disappear
for several seconds (doing its own upgrade) so we have 16 MByte FIFO beyond
the FX2.
We also had problems with overlapped IO which we wanted to use to have 20
MBytes of output queued. Output seemed to be re-ordered.
Cypress said their later driver is better. It implements
IOCTL_ADAPT_SEND_NON_EP0_DIRECT (instead of
IOCTL_ADAPT_SEND_NON_EP0_TRANSFER which requires the SINGLE_TRANSFER to
preced the data in memory). However, I am not sure it really helped and so
did not test it.
We did find technical support at http://www.cypress.com was reasonable
except when Bombay was flooded.
HTH
Bill
Article: 92405
"damir" <damir.makni@srce.hr> writes:
>Just to add small clarification -
>
>What happens is that output FIFO on FX2 is not emptied on time by PC host
>(using USB BULK IN transfers) - this results that internal FX2 FIFO gets
>full for significant amount of time and we are currently not able to
>compensate this using small FIFO implemented in FPGA.
>
>As the bandwidth we are using is only a fraction of bandwidth provided by
>USB 2.0, I'm suspicious about driver performance.
As Gabor pointed out, bulk transfers are not the right ones for streaming data.
On the one hand you get reliability due to the CRC checks and retries, on the
other hand bulk transfers have no bandwidth reservation.
BUT:
If you have luck, it is only your FX2 driver. I don't know what driver you are
using, but when doing only synchronous IO, your problem is much more likely to
appear (well, almost guaranteed to appear...).
Windows and Linux can do pipelining of transfers, but it involves asynchronous
driver calls and brings up tons of potential race conditions, which most lazy
driver writers want to avoid. If you use Overlapped IO (Windows terminology) or
Bulk Queuing (Linux), it should be possible to get a steady bulk transfer, as the
host controller has always enough transfer descriptors to run.
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Article: 92406MS Project is a worthwhile tool but to use it effectively you need to use it a reasonable amount. If like me you end up doing a bit here and there it is always a bit of a struggle to find the feature you want. Whatever you do you are it is best to break the job into manageable chucks with some kind of sub-task target to run against. When breaking down your sub-tasks think of things that mean that things don't happen as fast as you think. Lack of staff interaction during summer and christmas holiday seasons (sods law -they never take holidays at the same time) is one common event to think about. Usually I think up a time to do a task then multiply by 3 and that usually comes in about right normally. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk <gretzteam@hotmail.com> wrote in message news:1133279619.861418.105430@o13g2000cwo.googlegroups.com... > Hi, > I just got chosen as 'project manager' for our next project. It seems > like most people feel 'sorry' for me around here... We are designing a > moderately large mostly digital asic and the team consists of about 6 > people. I've never managed anything before and most of the people in > the team are more senior designer than me. Right now, things are > decided from hallway conversations, and nothing is really written down > in terms of schedule and who-does-what... > > I wonder what tools if any that people use to manage a project. Is > something like MS-Project any good? I understand that the schedule we > would put in place will never hold, but I figure it's better to have > something than nothing. Also, what do people use to track down bugs and > issues. The chip is divided in 6-7 blocks, each will be assigned to > one-two person. Where should I gather the information coming out of the > weekly meeting - schedule slip, bugs to be fixed etc...email? > ms-project? hallway? > > Thanks a lot, > > Dave >Article: 92407
As mentioned, we are using standar Cypress FX2 drivers and CyUSB and CyAPI. Damir "Georg Acher" <acher@in.tum.de> wrote in message news:dmhve0$dnk$1@wsc10.lrz-muenchen.de... > "damir" <damir.makni@srce.hr> writes: >>Just to add small clarification - >> >>What happens is that output FIFO on FX2 is not emptied on time by PC host >>(using USB BULK IN transfers) - this results that internal FX2 FIFO gets >>full for significant amount of time and we are currently not able to >>compensate this using small FIFO implemented in FPGA. >> >>As the bandwidth we are using is only a fraction of bandwidth provided by >>USB 2.0, I'm suspicious about driver performance. > > As Gabor pointed out, bulk transfers are not the right ones for streaming > data. > On the one hand you get reliability due to the CRC checks and retries, on > the > other hand bulk transfers have no bandwidth reservation. > > BUT: > > If you have luck, it is only your FX2 driver. I don't know what driver you > are > using, but when doing only synchronous IO, your problem is much more > likely to > appear (well, almost guaranteed to appear...). > > Windows and Linux can do pipelining of transfers, but it involves > asynchronous > driver calls and brings up tons of potential race conditions, which most > lazy > driver writers want to avoid. If you use Overlapped IO (Windows > terminology) or > Bulk Queuing (Linux), it should be possible to get a steady bulk transfer, > as the > host controller has always enough transfer descriptors to run. > > -- > Georg Acher, acher@in.tum.de > http://www.lrr.in.tum.de/~acher > "Oh no, not again !" The bowl of petuniasArticle: 92408
If you haven't managed a project before it might be better to avoid the hassle of a new tool such as MS-Project and simply model it on a whiteboard until you get comfortable with things. And get yourself some training in techniques of project management (not tools), including the soft skills. AlanArticle: 92409
im trying to reverse engineer a windows driver for a PCI fpga development board so i can use it on a linux machine (write my own driver) all i need are the command and control signals in order to configure, do dma, reset, etc... i need to capture these things as they are being sent from the windows kernel to the PCI bus, then to the pci bridge on the board. anyone have any ideas?Article: 92410
Have a look at Seamless FPGA from Mentor Graphics. Although primarily for verification, it can also give you performance stats (cache hit/miss, code profiling, bus utilization). Kunal > > Paul > > Joseph Samson wrote: > >>Martin Schoeberl wrote: >> >>>>HI group, >>>> >>>>I am searching for some technique which can give me instruction count >>>>and cache hits/misses for a configuration created using Xilinx FPGA. >>>>I have bitstream corresponding to that configuration. >>>>My objective is to get the following statistics such as instruction >>>>count and cache hits/misses for any application executing on the system >>>>configuration downloaded on FPGA. >>>> >>> >>>That's a very strange question. Instruction count and cache >>>misses are related to processors and do not apply to FPGAs >>>per se. You can implement a processor as soft-core in the >>>FPGA and than it's easy to add all your measurement registers >>>in the FPGA. >> >>I think the poster wants to know these statistics for the embedded >>PowerPC processor. This is actually very important for users who want to >>optimize their PPC code. Perhaps one of our Xilinx regulars can provide >>some hints. >> >>--- >>Joe SamsonArticle: 92411
thank you Eilert. Unfortunally it doesn't compile, imo it's the same
as you wrote:
# ** Error: D:/electronic/projects/la/la/source/vhdl/sub.vhd(33):
Length of expected is 17; length of actual is 16.
# ** Error: D:/electronic/projects/la/la/source/vhdl/sub.vhd(40):
Length of expected is 17; length of actual is 16.
The same error I get on using unsigned of ieee.numeric_std. Here the
complete file:
---8<---
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
entity sub is
end entity sub;
architecture behave of sub is
constant BIT_WIDTH : natural := 16;
constant PERIOD : time := 10 ns;
signal lower_bound : std_logic_vector(BIT_WIDTH-1 downto 0);
signal upper_bound : std_logic_vector(BIT_WIDTH-1 downto 0);
signal x : std_logic_vector(BIT_WIDTH-1 downto 0);
signal out_of_limits : std_logic;
signal within_limits : std_logic;
signal le, ge : std_logic;
signal tb_clk : std_logic := '0';
signal tb_done : boolean := false;
begin
tb_clk_proc : process is
begin
tb_clk <= '0';
if tb_done then wait; end if; -- stops clock
wait for PERIOD/2; -- clock low
tb_clk <= '1';
wait for PERIOD/2; -- clock high
end process tb_clk_proc;
le_proc : process (upper_bound, x) is
variable diff : std_logic_vector(BIT_WIDTH downto 0);
begin
diff := upper_bound - x; -- LINE 33
le <= diff(BIT_WIDTH);
end process le_proc;
ge_proc : process (lower_bound, x) is
variable diff : std_logic_vector(BIT_WIDTH downto 0);
begin
diff := x - lower_bound; -- LINE 40
ge <= diff(BIT_WIDTH);
end process ge_proc;
within_limits <= le and ge;
out_of_limits <= le xor ge;
tb : process is
begin
lower_bound <= conv_std_logic_vector(27, BIT_WIDTH);
x <= conv_std_logic_vector(0, BIT_WIDTH);
upper_bound <= conv_std_logic_vector(129, BIT_WIDTH);
wait until rising_edge(tb_clk);
-- report "within_limits = " & std_logic'image(within_limits);
-- report "out_of_limits = " & std_logic'image(out_of_limits);
assert (out_of_limits = '1') and (within_limits = '0')
report "test failed" severity error;
tb_done <= true;
end process tb;
end architecture behave;
Thanks
Olaf
Article: 92412"Duane Clark" <dclark@junkmail.com> wrote in message news:LQ_if.34338$6e1.906@newssvr14.news.prodigy.com... > Fred wrote: >> Have a problem so tracing signals. What's a X_LUT3? A standard LUT3 >> only has an INIT value of 0 to 7. This is the "...translate.vhd" file >> which has this primitive and an INIT value of x"EB". >> >> Q_n0024_0_1 : X_LUT3 >> generic map( >> INIT => X"EB" >> ) >> port map ( >> ADR0 => cycle(2), >> ADR1 => cycle(0), >> ADR2 => cycle(1), >> O => Q_n0024(0) >> ); > > All of the X_* components are simprim primitives. You can find out what it > is by looking at the file simprim_VITAL.vhd. Many thanks.Article: 92413
On Mon, 28 Nov 2005 17:51:52 -0800, Athena <lnzhao@emails.bjut.edu.cn> wrote: >Thank PeteS very much for your help. I got it. > >Still I want to ask whether there is someone who have successfully boot from flash or have some documents or examples to show the method. > >Thank you > >Athena Could this give a hint ?? http://sourceforge.net/projects/lubloader/ http://www.newae.com/loonboard/lub.html CarstenArticle: 92414
"damir" <damir.makni@srce.hr> wrote in message news:dmhhe6$ej8$1@bagan.srce.hr... > We have developed data acquisition system which uses Cypress FX2 as the > USB 2.0 interface. State machine for control and conversion of data > between AD converters and FX2 is implemented using Xilinx Spartan 2 FPGA. > The problem is that with higher data rates (up to 25 Mbit/s) we experience > FX2 internal FIFO stalls and missing data on the receiving side. Small > FIFO implemented inside FPGA does not help to resolve the problem. On the > PC, data acquisition is implemented using CyAPI & CyUSB. USB bulk mode is > used for transfer. > > As mentioned data rate is only a fraction of USB 2.0 bandwidth, I don't > know if the mentioned problem is related to the implementation of the > receiver side (CyAPI) or lacking capability to sustain such bandwidth > within Cypress FX2. > > Did anyone have similar problems using FX2 and how you manage to solve it? > > I will appreciate any help to resolve this problem, if possible in > software - hardware solution will require redesign of the PCB and > implementation/addition of large size FIFO to buffer FX2 stalls (which > may, according to our experience, extend up to 50 ms). > > Thanks, > > Damir > > > You can also try to increase priority of your PC application. We had the similar problem and fortunately we could rise the priority up to Realtime, as the data arrived in bursts, so we didn't kill the rest of the system... - Dejan P.S. mozete me dobiti na donju adresu (jasno je sto treba maknuti), ako je potrebno... dejan@dilogic.removeme.hrArticle: 92415
"Philip Freidin" <philip@fliptronics.com> wrote in message news:ji6mo15amnurn107gkp4s0a4uof39pkrbp@4ax.com... > > I think it is best to distribute the signal on your PCB. > ..but be aware of the load you're placing on the signal. The FPGA's pins have considerable capacitance. If you wire the signal to 8 pins, you could have 100pF loading the end of your line. This gives you a rise time of the order of 5ns if driven from 50 ohms. The timing might be skewed as the signal rises through the thresholds of the inputs. Cheers, Syms. p.s. I'm wondering if you could use some spare unbonded IOBs for this? Take the signal in. Distribute it with low skew (easy to say!) to the outputs of 4 or 8 unbonded IOBs. Use the input delay thingies? The same as previously suggested, but without using up real IOBs?Article: 92416
damir wrote: > I need to implement slow FIFO (16-bit wide, max. 10 MHz) using external > single-port SRAM connected to the FPGA (Spartan II/III). > > Does anyone have similar FIFO controller (sync/async) implemented using > VHDL? A FIFO in a single-port RAM? Neat trick, although I suppose the slow speed makes it do-able. -aArticle: 92417
Olaf Petzold wrote:
>
> # ** Error: D:/electronic/projects/la/la/source/vhdl/sub.vhd(33):
> Length of expected is 17; length of actual is 16.
> # ** Error: D:/electronic/projects/la/la/source/vhdl/sub.vhd(40):
> Length of expected is 17; length of actual is 16.
>
>
> architecture behave of sub is
> constant BIT_WIDTH : natural := 16;
OK, so BIT_WIDTH is 16.
> constant PERIOD : time := 10 ns;
> signal lower_bound : std_logic_vector(BIT_WIDTH-1 downto 0);
> signal upper_bound : std_logic_vector(BIT_WIDTH-1 downto 0);
lower_bound and upper_bound are (15 downto 0), or 16 bits wide.
> signal x : std_logic_vector(BIT_WIDTH-1 downto 0);
x is also (15 downto 0), 16 bits wide.
> le_proc : process (upper_bound, x) is
> variable diff : std_logic_vector(BIT_WIDTH downto 0);
diff is (16 downto 0) or 17 bits wide.
> begin
> diff := upper_bound - x; -- LINE 33
Here's the problem, and the error message is quite explicit.
upper_bound and x are both 16 bits wide, and you're assigning them to a
17-bit vector.
> ge_proc : process (lower_bound, x) is
> variable diff : std_logic_vector(BIT_WIDTH downto 0);
> begin
> diff := x - lower_bound; -- LINE 40
Same here: x and lower_bound are 16-bit values assigned to a 17-bit
value. Can't do that.
You simply need to extend x, upper_bound and lower_bound to be the same
width as your result. In other words, something like (using
numeric_std and appropriate types, either unsigned or signed):
diff := resize(x, diff'length) - resize(lower_bound, diff'length);
oughta work.
-a
Article: 92418I would design a reasonably fast state machine ( 50 MHz?) that keeps track of the read and write requests, updates the two addresses and multiplexes them appropriately to the external SRAM. If read-access time is important, you could always pre-fetch the next entry and store it in an on-chip register. The state machine must check for the two addresses becoming equal. If read causes them to become equal, the FIFO is empty, if write causes it, the FIFO is full. The slow speed makes all this possible, and even easy. Don't worry too much about metastability of the control circuitry. Just make sure that there is an extra 5 ns of settling-time slack available. Peter Alfke, Xilinx ApplicationsArticle: 92419
Thanks for the hint, I'll try this approach! Damir "Peter Alfke" <peter@xilinx.com> wrote in message news:1133292476.312758.278240@f14g2000cwb.googlegroups.com... >I would design a reasonably fast state machine ( 50 MHz?) that keeps > track of the read and write requests, updates the two addresses and > multiplexes them appropriately to the external SRAM. If read-access > time is important, you could always pre-fetch the next entry and store > it in an on-chip register. The state machine must check for the two > addresses becoming equal. If read causes them to become equal, the FIFO > is empty, if write causes it, the FIFO is full. > The slow speed makes all this possible, and even easy. > Don't worry too much about metastability of the control circuitry. Just > make sure that there is an extra 5 ns of settling-time slack available. > Peter Alfke, Xilinx Applications >Article: 92420
amyler@eircom.net wrote: > If you haven't managed a project before it might be better to avoid the > hassle of a new tool such as MS-Project and simply model it on a > whiteboard until you get comfortable with things. > > And get yourself some training in techniques of project management (not > tools), including the soft skills. > > Alan > I agree. First get the project management skills developed, then worry about the scheduling (which is only one part of the project management). -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 92421
Carsten wrote: > On Mon, 28 Nov 2005 17:51:52 -0800, Athena <lnzhao@emails.bjut.edu.cn> > wrote: > > >Thank PeteS very much for your help. I got it. > > > >Still I want to ask whether there is someone who have successfully boot from flash or have some documents or examples to show the method. > > > >Thank you > > > >Athena > > Could this give a hint ?? > http://sourceforge.net/projects/lubloader/ > > http://www.newae.com/loonboard/lub.html > > Carsten The OP is not clear about 'boot from flash'. Does (s)he have a processor instantiated that boots from external flash? Is this a method of loading the FPGA from an ordinary flash? Those are two different things Cheers PeteSArticle: 92422
damir wrote: > I need to implement slow FIFO (16-bit wide, max. 10 MHz) using external > single-port SRAM connected to the FPGA (Spartan II/III). > > Does anyone have similar FIFO controller (sync/async) implemented using > VHDL? > > Thanks, > > Damir I would put two small FIFOs on the FPGA, and then have a simple, synchronous state machine to control the external RAM. The state machine would look at how full/empty the FIFOs are, and based on their priority determine whether it will do a either a read or write access to the external RAM. If you need an asych FIFO, then use one of the on-chip FIFOs to cross the clock domains, and keep the rest on the same clock.Article: 92423
damir escreveu: > We have developed data acquisition system which uses Cypress FX2 as the USB > 2.0 interface. State machine for control and conversion of data between AD > converters and FX2 is implemented using Xilinx Spartan 2 FPGA. The problem > is that with higher data rates (up to 25 Mbit/s) we experience FX2 internal > FIFO stalls and missing data on the receiving side. Small FIFO implemented > inside FPGA does not help to resolve the problem. On the PC, data > acquisition is implemented using CyAPI & CyUSB. USB bulk mode is used for > transfer. > > As mentioned data rate is only a fraction of USB 2.0 bandwidth, I don't know > if the mentioned problem is related to the implementation of the receiver > side (CyAPI) or lacking capability to sustain such bandwidth within Cypress > FX2. > > Did anyone have similar problems using FX2 and how you manage to solve it? > > I will appreciate any help to resolve this problem, if possible in > software - hardware solution will require redesign of the PCB and > implementation/addition of large size FIFO to buffer FX2 stalls (which may, > according to our experience, extend up to 50 ms). > > Thanks, > > Damir > > > I use the SX2 and could get around 25Mbit/s of sustained transfer in bulk mode, but remember that bulk transfers have absolutely no time guaranty. Even interrupt and isochronous that should have timeliness have a disclaimer in the USB specification that real timeliness is dependant upon SO. Windows and Linux can take a very long time without giving the processor to any specific task. I did no test at all regarding latency in this case. Depending on how critical is the data, you may need over 1s of buffering. Using drivers in windows i've seen sub-ms response times, but there's no way to be sure it will allways be so. I think the Cypress driver is quite slow also. In the test I achieved 25mBit/s the FPGA driving the SX2 could deliver over 120Mbit/s to the SX2, which sould be capable of even more.... RicardoArticle: 92424
gretzteam@hotmail.com wrote: > Hi, > I just got chosen as 'project manager' for our next project. It seems > like most people feel 'sorry' for me around here... We are designing a > moderately large mostly digital asic and the team consists of about 6 > people. I've never managed anything before and most of the people in > the team are more senior designer than me. Right now, things are > decided from hallway conversations, and nothing is really written down > in terms of schedule and who-does-what... > > I wonder what tools if any that people use to manage a project. Is > something like MS-Project any good? I understand that the schedule we > would put in place will never hold, but I figure it's better to have > something than nothing. Also, what do people use to track down bugs and > issues. The chip is divided in 6-7 blocks, each will be assigned to > one-two person. Where should I gather the information coming out of the > weekly meeting - schedule slip, bugs to be fixed etc...email? > ms-project? hallway? > > Thanks a lot, > > Dave > I'm not sure what "project manager" means at your company, but if you can't fire anyone you're not a manager. If someone calls you a manager, with or without the word "project" in front, holds you responsible for results, but doesn't let you hire and fire then you're not a manager, you're a future scape goat. If you're lucky you won't be held responsible for schedule slips &c. If you're not lucky then the piece of software you most need is your friendly local word processor, for resume composition. As mentioned elsewhere, you want to understand project management skills before you bother getting the tools. If you can't do it with index cards and magnets on a whiteboard then you can't do it with Project. When that poster mentioned "soft skills" he meant the people skills to manage your troops _and_ the political skills to get the resources you need to succeed from your superiors. This cannot be underrated -- I have never known a truly successful project manager who could not get what he needed from higher-ups, nor have I seen one who could not get people to do what he felt was necessary, even if no one else could. Enough of that. However you manage your schedule data, you need to have a solid estimate. I've found two ways to accurately estimate a project: wideband delphi (do a web search) and looking at how long it took to do the last project. The second option only works if you've done something similar; wideband delphi is very accurate but it takes a long time (it also refines the project definition, so you can call it "preliminary design" if you can get people to cooperate). No matter what, if you track the actual schedule against your original estimate you can at least have an estimate of when you'll actually be done. Not only can you use this estimate to motivate the troops, but you can use it to warn your boss that things aren't going as fast as expected. Track bugs with a data base. I prefer a real honest computerized database, either a pre-written package designed for bug tracking or a custom application written on the data base of your choice. At any rate you need to be able to track the progress of bug fixes and feature additions from cradle to grave, you need to know whether they are newly discovered, who's currently responsible for them, whether they've been fixed, whether the fix has been tested, and if they've been put to bed. I'd start with a purpose-written application, if I could find a good one (do a web search). -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
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