Jump to content

jserot

Members
  • Content Count

    16
  • Joined

  • Last visited

About jserot

  • Rank
    Member

Recent Profile Visitors

431 profile views
  1. Thanks for the suggestion, Raph. Will have a look. Jocelyn
  2. The consumer should never block in my case. Reading twice a shared variable which has only been written once should not block the reader...
  3. Ok, thanks. This is indeed what i suspected. Exactly. In fact, this is the kind of solution i'm investigating. I'm starting from a compiler internal representation of the application as a graph of FSMs connected via shared variables. Each FSM is implemented as a SystemC module. The idea is to extract from the graph the chain of dependencies - i.e. which module(s) read (resp. write) each variable - and to insert delta wait(s) at the right place(s). In the example above, this would involve rewriting B as void B::my_thread() { while ( 1 ) { wait(h.posedge_event())
  4. Hi Roman, thanks for your feedback. Instantaneous broadcast - also called "perfect synchrony" - means that any update performed to a shared value by a component (a module in our case) will be viewed immediately by other components (and not after n delta cycles, as for sc_signals). Here's a typical example, with two modules : - module A waits for (global) event H (a clock typically) and, when received, set shared variable v to 1 - module B also waits for H but when received only performs action xxx if v=1 (in StateChart, this is called a guarded transition) void A::
  5. Hi, Sorry for resurrecting this post but it addresses an issue i'm currently facing. Does this mean that it is not possible to implement instantaneous broadcast (as used in StateCharts or synchronous reactive models of computation for ex.) in SystemC ? With the latters, the undeterminacy is resolved by iterating until a fix-point is reached so that the final values of shared variables do not depend on the order of (micro)-steps ? Jocelyn
  6. Ok; i should have spotted this myself ;-) Now it works correctly. Thanks _a lot_ for your help ! Best wishes Jocelyn
  7. Dear all, Thank for your answers. Sorry, i dont understand. What i'm trying to do is to trace value change on a signal - there surely must be a way to do this since tracing a sc_signal is obviously possible.. For the SC_KERNEL_EVENT_PREFIX, you're right, i can probably get rid of this (i just copied this line from the sc_fifo.h..) Thanks for the suggestion, Alan. I tried this, adding this definition after the buffer_in class definition in my .h file (incidentally, i had to make the m_sig member public for this) : template<class T> void sc_trace(sc_trace_fi
  8. Dear all, I'm implementing a custom channel which is basically an hybrid object, offering a fifo-lile interface on the reader side and a signal-like interface on the writer side. The code is given below (listing 1). Basically, it just wraps up a sc_signal so that it can be viewed as a never-empty FIFO on the reader side. It works well except that the value changes -- that are correctly witnessed by issuing print msg in the write() method() -- are not dumped in the trace file (see listing 2). My intuition is that the write actions are not viewed by the trace mechanism and that i sho
  9. This is exactly what i've been doing up to now ! But since my specific fifo is very similar to the sc_fifo, this implies a lot of copying. This is that copying I was wishing to avoid by using inheritance. I've read a bit on multiple inheritance issues since yesterday (since i'm not basically a C++ specialist..) : not trivial ones, apparently ! Thanks for the feedback anyway
  10. Thanks a lot for the tip, Philipp. I haven't thought about this since i'm not familiar with the TLM layer. Will try ! This said, i find it awkward that the sc_fifo class cannot be easily extended. Is it a consequence of the limitations of the C++ inheritance mechanism or a deliberate choice of the SystemC designer ? Jocelyn
  11. Hi, I reactivate this thread because I've stumbled on the same problem recently and can't seem to find any answer after having crawled the web for a while. I understand the pb with the second solution and tried the one given by Philipp (wrapping a sc_fifo instance inside my special fifo class). Unfortunately, it does not work if the "derived" (wrapping) class needs to access non-public members of the wrapped class. In my case, i wand to add a method virtual T peek(void); which simply returns the data at the top of the FIFO without popping it (non destructive read). There's no
  12. Philip, The type inference phase is carried out on a backend-independant representation. In this particular case, the tricky thing to do is to map the types computed at this level to SystemC types because, as you rightly puts it, there a significant number of corner cases (and the VHDL backend is even worst..). The solution you suggest (inserting unary + or equiv) will unfortunately not work in all cases, because _any kind_ of expression can appear as an argument of the ternary cond operator (sorry, it's difficult to be more explicit w/o showing the intermediate representation and associat
  13. You guessed right, Alan The bug will be fixed in vers 1.6 (not by replacing the cond op by an "if" but by using the result of the type inference phase to insert the proper type cast when requested). Best regards Jocelyn
  14. Thanks a lot Philipp ! I was suspecting sth like this but was not aware doing arithmetic on one operand was actually changing its type (compared to the other one). In fact, i had searched the sc_int class for an (overloaded) version of the arithm operators (+, _, ...) and was a bit puzzled not to find them. Anyway, this explains the problem. ... but incidently, does not simplify my life - since the code in question is actually not written by hand but generated by a compiler (more details on this here, in case you would be interested : http://dream.univ-bpclermont.fr/index.php/en/softmenu/
  15. Thanks for your reply. Sorry. My code was confusing. Of course, when compiling, i comment out one of the two lines containing the return statement. To be clearer : This compiles ok : template<int n> sc_int<n> f_abs(sc_int<n> x) { if ( x <0 ) return 0-x; else return x; }; But this fails to compile : template<int n> sc_int<n> f_abs(sc_int<n> x) { return x<0 ? 0-x : x; };
×
×
  • Create New...