Joined

Last visited

Community Reputation

About Chris_C

Profile Information

While this isn't specifically fpga related I never the less think it a most cromulent way to play with logic networks... I'm considering making a none grid based more utiliterian logic simulator, now that I've proved that my state chage event system is suitable to simulate logic networks. While its really a toy I've been able to simulate adding 2, 4-bit values... You can read about it here http://chrisc.bedroomcoders.co.uk/logic-toy-a-logic-simulation-toy/ and grab the source here https://github.com/chriscamacho/LogicToy Enjoy !

Suppose I want my design to "load" data from the flash chip into sdram, at the moment I'd need a separate design to load data over serial (slow and painful even at 115200) save it temporarily in sdram and then write it into the flash If instead I could use the loader app with an offset I could upload the data to say +1mb in the flash at full USB speed AFAICT there is no parameter to specify where the data should start I suppose I could take my bit file pad it out at the end with zeros and add the data on the end but then thats going to make a very large file to upload...

yes, condition codes it is! I don't think life without at *least* a carry flag would be much fun! I'm still trying to work out if I really need a stack, while it would make call/return and even parameters easier - I'm still investigating alternatives.

Obviously condition codes are useful, but for some reason I was attempting to see if they were really needed... I've never seen the point of fixed(immediate) offsets ? I did intially attempt a fixed size of all instructions but kinda seemed to end up with lots of wasted space for a bunch of instructions I'm trying to weigh up if a single return address is sufficient or if I need to implement a call stack I'll PM you with my email, it may be that we can help each other by batting ideas back and forth!

These are good points especially subroutines and returns (can't see how to fit it into the current set) I decided to restrict it to an 8 bit bus initially (there may be son and even granson of this cpu!) to reduce complexity and also to ensure it doesn't take up lots of room... While I can see the attraction of stack machines (from a hardware designers point of view) I've never particularly enjoyed programming them, this will be a machine I'll code in assembler and don't have a need for a C compiler That said they are all good points especially subroutines / return, thank you very much for your constructive points. hmmm NOP and SPARE - I did leave myself wiggle room for call / return.... (but this would need a call stack)

@johnbeetem logisim http://www.cburch.com/logisim/ is simple even does rudimentary propagation delay and is fantastic getting the pure logic right! You can bash together a logic circuit to test you logic is OK in probably less then 10% of the time you could using schematic capture / simulation and its a lot more user friendly! @hamster I'm missing the point as i fail to see how that's better than a counter ? (the pulses must be at least 6 clocks apart?) Perhaps you'd like to make a separate post so others don't miss it?

My code as it stands now is working! I wanted to get a better understanding of rising / falling generally Add and end process and three endifs and throw something inside the ifs so they don't get optimised out and that should reproduce the error If you are particularly interested I could try to reintroduce the error into some fresh code One thing I find tiresome about the tools. (One of many things alas) is the fact it would simulate just fine, but not synthesise - what's the point of a simulation that doesn't actually simulate the limitations of the target device !

Unfortunately I rewrote the code to work round it but in one process DoPulse process(clk,pulsein) If rising_edge(clk) ... If falling_edge(clk) ... If falling_edge(pulsein) I can see why it would complain about falling clk but after its removal it complained about falling pulse in Is it possible to drive 2 buffers from say clk and detect rising on the output of one buffer and falling on the other ?

Allthough I could simulate some code which conditionally checked rising and falling edge, when it synthisised it spewed yet another cyptic error message statement is not synthesizable since it does not hold its value under NOT(clock-edge) I really need an error message to english translator! So I changed my logic about for the input it was complaining about and eliminated the falling edge check then it complained about the same thing but for a different input should I be using different processes for rising and falling edge, but then whats the best way to "communicate" between processes for example I can't really see how hardware could drive the same signal from two places? Assuming my logic really could only be done by detecting rising AND falling edge whats the best way to go about it... (incidently by changing my logic round I have a working module but I'm interested to learn about this for future pain with ISE)